セキュリティギャップのすり抜け：組織を狙うアプリケーションおよび API 攻撃の増加
エグゼクティブサマリー
Web アプリケーションおよび API 攻撃の件数が増加しており、特定された攻撃トラフィックの量は約 2.5 倍に増えました。この増加には、API の採用の拡がりと脅威活動の増加の両方が寄与していると考えられます。
Web アプリケーションおよび API 攻撃を最も増やしている脅威ベクトルが、ローカル・ファイル・インクルージョン（LFI）です。LFI 攻撃は前年比で 193% 増加しており、これは 2021 年の 3 倍に当たります。
API のビジネスロジックを狙う API 攻撃は検知と緩和が困難です。そのため、リクエスト単位での判断はいっそう難しくなっています。
サーバーサイド・リクエスト・フォージェリ（SSRF）やサーバーサイド・テンプレート・インジェクション（SSTI）といった新たな攻撃ベクトルは、組織にとって今後も深刻な脅威であり続けると予想されます。攻撃者は、SSTI の技法を危険な ゼロデイ 脆弱性、例えばリモートコード実行につながる Log4Shell や Spring4Shell と組み合わせて使用していました。
直販業界（小売業など）とは違って、大量の API リクエストを処理する必要が基本的にない主要業界（製造業など）で、攻撃が急増しています。
Akamai は、最新の「インターネットの現状／セキュリティ」レポート「セキュリティギャップのすり抜け：組織を狙うアプリケーションおよび API 攻撃の増加」で、Web アプリケーションと API のトラフィック分析、重大な脆弱性、業界別のリスクに基づき、攻撃の傾向をまとめています。また、このレポートには、調査結果に加えてベストプラクティスや緩和戦略も盛り込まれています。
API とアプリケーションの間のギャップは脆弱性となり、境界を侵害し、ネットワーク内部へ侵入して、機密情報の取得をうかがう攻撃者にとって悪用の機会になります。 また、Web アプリおよび API 攻撃は引き続き、対処が必須の危険な脅威であることから、リスク軽減のためには、セキュリティバグのパッチをタイムリーに適用することが欠かせません。
（セキュリティ）ギャップに要注意：API 攻撃に関する調査がリスクを浮き彫りに
当社のデータは、Open Web Application Security Project（OWASP）による API Security Top 10 の公開候補版を裏付けています。このリストの新たな顔ぶれは、いっそう API 固有寄りになっています（図 1）。この候補リストに API 脆弱性が含まれていることは、Web アプリケーションの脅威の重視から転換したことの表れと見られ、組織による対処が欠かせない API 攻撃によるリスクの増加を浮き彫りにしています。
図 1：提案された新たな API Security Top 10 には API 固有の攻撃が増えており、認証に関する課題が強調された形に（攻撃の上位 5 つのうち 4 つ）
壊れたオブジェクトレベル認可
壊れたオブジェクトレベル認可（BOLA）は、提案された OWASP API Security Top 10 のトップにランクインしている API 脆弱性です。暗号破り（API ロジックに内在する瑕疵）のような技術寄りのアプローチを要さないものの、正当なトラフィックに似ており、検出が非常に困難な場合があります。また、攻撃者が BOLA 攻撃に対して脆弱な API エンドポイントをスキャンできることから悪用が容易で、攻撃が成功すれば、保管されている個人情報など、他のユーザーの情報にアクセスできるようになって、有害なリスクとなる可能性があります（図 2）。
図 2：標準的なリクエスト vs BOLA 攻撃
BOLA 攻撃によるリスクを緩和するためには、以下がベストプラクティスとなります。
クライアント入力を使用する API の認可チェックを実装し、リクエストされたリソースに現在のユーザーがアクセスできるかどうかを確認
リソース ID に連番の数値 ID ではなくユニバーサル一意識別子（UUID）を使用
API エンドポイントに BOLA の脆弱性がないかどうかを評価するためにテストを作成し実施
認証の不備
Akamai では、認証の不備（新しいリストで 2 位）にもスポットライトを当てています。この脆弱性では、アカウントにアクセスしているのが認証ユーザーかどうかの検証や確認に弱点があります。この類いの攻撃は、ある程度の技術ノウハウが必要で、難しいのですが、ひとたび成功すればアカウントが乗っ取られるなどして危険です。このことから、リスクが見直されて認証フローのリスクが含められており、安全なアルゴリズムを使用すること、ペイロードに機微な情報を格納しないこと、kid パラメーターでは生成された一意識別子を使用すること（使用する場合）が求められています。
脆弱性と新たな攻撃ベクトルの年
2022 年はアプリケーションおよび API 攻撃に関して記録的な年で、ゼロデイ脆弱性との戦いが続きました。2021 年末、組織は Log4Shell に続いて、Atlassian Confluence の脆弱性、ProxyNotShell、Spring4Shell というまた別の重大な脆弱性の標的になりました。
マルウェアに関しても新たな傾向が見られました（SSTI やサーバーサイド・コード・インジェクションなど）。これらはリモートコード実行やデータ流出を招きかねず、ビジネスに深刻な脅威を与えています。さらに、SSRF 攻撃が急増しました。Akamai では、当社のお客様の内部リソースへのアクセスを許しかねない Web アプリケーションや API に対する SSRF 試行を、1 日平均 1,400 万件観測しました。
オープン・ソース・ソフトウェアのゼロデイ脆弱性は、リモートコード実行を許す SSTI の技法とともに蔓延しつつあります。また、攻撃者が持続的標的型の攻撃や HTTP リクエストスマグリングで Web シェルを活用していることも観測されています。
デジタライゼーション時代のアプリおよび API のリスク：業種による攻撃の違い
Akamai では、主な業種や傾向、およびサイバー犯罪者が組織への侵入経路として API やアプリケーションを使うことの多い方法についても検証しました。攻撃の頻度は多くの業種で増加しており、リストの上位にはコマース、ハイテク、金融サービスの各業界が挙がっています（図 3）。金融サービスがトップ 3 にランクインしていることに驚きはありません。これは昨年の SOTI レポート、「 差し迫る敵：金融サービスに対する攻撃の分析」に盛り込まれた Akamai の知見の反映です。このレポートでは、金融サービスへの攻撃が 3.5 倍に急増したことを明らかにしています。
加えて、コマース業界で LFI 攻撃が劇的に増加しました。コロナ禍を契機に、新しいアプリケーションやテクノロジーを迅速に導入する動きが増えましたが、おそらく攻撃者は、脆弱性などの悪用できるセキュリティギャップを探し出すことで、この動きを利用しています。
図 3：Web アプリケーションおよび API 攻撃の影響を受ける業種の上位はコマース、ハイテク、金融サービス
別の視点
一方、中央値のデータセットに目を向けると、業種別のさまざまな攻撃について異なる展望がもたらされます。このデータを見ると、製造業は 2022 年の攻撃件数でハイテクおよび金融サービス業界を上回っています。これは、Akamai の最新 SOTI レポート「 攻撃の「高速道路」：悪性 DNS トラフィックの詳細な分析 」や当社のグローバルなランサムウェア脅威レポートとも一致しています。
メーカーには、小売業などの直販業界と同じ規模のアプリおよび API 攻撃に対処する必要こそありませんが、インシデントが発生すればその影響は深刻です。それに、2022 年における攻撃の中央値の急増（76%）は厄介です。この業界の運用テクノロジーへのサイバー攻撃が成功すれば、サプライチェーンの問題と同様、現実的な影響が生じます。
最後に、ヘルスケアおよび製薬企業への攻撃の中央値も増加しています（82%）。その火付け役は医療の IoT（IoMT）の導入で、これによりアタックサーフェスが拡大しました。多くのヘルスケアプロバイダーが、レガシーシステム、高度なフェデレーテッドシステム、IoMT データを数々抱えている現状では、データフローのセグメンテーションと可視化を強固にすることが重要です。患者の安全は非常に重要で、リスクにさらすわけにはいきません。
ギャップを埋めることに関する考察
このサマリーでは、Akamai のレポートに盛り込まれている豊富なデータや技術的な詳細を一部ご紹介しました。レポート全体に目を通し、そこから得られる教訓をビジネスに活かしていただければ幸いです。
推奨事項：
各種の新たな脆弱性やゼロデイ脆弱性の緩和を、危機が起こるのを待たず、プロトコル（コード）、製品、ファームウェアのどこで見つかるかにかかわらずご検討ください。それぞれの緩和策には少しずつ異なるプレイブックが必要となることもありますが、プロセスを確立しておくことはタイムリーな対応にとって非常に重要です。
攻撃ベクトルの緩和策として、エッジでの Web アプリケーションおよび API 保護／Web アプリケーションファイアウォール （WAAP／WAF）、内部的な セグメンテーション／リングフェンシング、およびソースに対してできるだけ迅速にパッチ適用を実施してください。
レポートで議論している主な課題と技法を参考に、侵入テスト／レッドチーム（攻撃者視点での検証）の立案を促進し、リスク体制を検証できるようにします。業界ごとに、場合によっては地域ごとに分析してください。他社のミスから学びましょう！
次の大きな脆弱性がいつ露わになるとも限りません — 自社のプレイブックを今すぐ作成または検証してください。
結論
まず、 OWASP に見られる変化 を確認し、ついで優先事項について検討しつつ、OWASP による最新の推奨事項をたたき台に検討を始めてください。アプリケーションが貴社のリスク選好を確実に満たすようにするためには、セキュリティが確保されたコード開発の実践と、ベストプラクティスや技術的な制御の開発が引き続き必要であり、JSON Web Token の認証の不備に関する特集はその格好の事例研究です。
このレポートのデータによる知見が、貴社の計画の刷新やベストプラクティスの開発のお役に立てば幸いです。
最新の調査結果やその他の知見については、 セキュリティ・リサーチ・ハブで取り上げられている既知の API の脆弱性などを検知します。
