OWASP API セキュリティトップ 10 に新たな変更がありました。これは私たちにとって何を意味するのでしょうか?

Open Worldwide Application Security Project (OWASP) は最近、2019 年以来初めて更新された API セキュリティトップ 10 ドキュメントのリリース候補 (ドラフト) をリリースしました。このドラフトで提案された変更を確認し、現在 API の脆弱性に影響を与えている主な要因を確認して、API のセキュリティ保護への取り組みをよりよく理解できるようにしましょう。

あらゆるところに潜むセキュリティの脅威に対して、Akamai のセキュリティソリューションが「保護シールド」を構築します。

Akamai セキュリティソリューションの詳細

いつでもどこでもあらゆるセキュリティリスクを把握できます。

OWASP Top 10とは何ですか?

OWASP は、コミュニティのフィードバックと専門家の評価に基づいて、今日の組織で見つかる最も一般的なタイプの脆弱性を説明するセキュリティ認識ドキュメントを作成する非政府組織です。

OWASP Top 10 は 2003 年に初めて公開され、定期的に更新されています。 TOP 10 の対象者は、開発者からセキュリティアナリスト、CISO まで多岐にわたります。ドキュメントのより技術的な側面に重点を置く人もいれば、購入した製品が適切な範囲をカバーしていることを確認するために使用する人もいます。

OWASP API トップ 10

OWASP は、Web アプリケーションセキュリティトップ 10 に加えて、API セキュリティには独自のアプローチが必要であることを強調する別の API トップ 10 ドキュメントを公開しています。 OWASP API セキュリティプロジェクトは、「アプリケーションプログラミングインターフェイス (API) 固有の脆弱性とセキュリティリスクを理解し、軽減するための戦略とソリューションに重点を置いています。」

API トップ 10 は 2019 年以降更新されていません。それ以来、API への依存は業界全体でさらに広まり、開発者の 70% が今年は API の使用が増えると予想しています。

OWASP API セキュリティトップ 10 リリース候補の最新アップデートが利用可能になりました。今日の API の脆弱性の状況がどのように変化したかを確認してみましょう (図 1)。

図1: 2019年以降のOWASP APIトップ10の変化

最近の変更点のハイライトは何ですか?

API3:2023 BOPLA と API1:2023 BOLA の違いは何ですか?

一括割り当てと過剰なデータ開示は、Broken Object Property Level Authorization (BOPLA) に統合されました。 BOLA (Broken Object Level Authorization) と BOPLA の違いは、BOLA がオブジェクト全体を参照するのに対し、BOPLA はオブジェクト内の属性を参照することです (図 2)。

図2: BOPLAはオブジェクト内の属性を参照します

新しい定義では、防御側がオブジェクトをより深く調査する必要があり、攻撃を検出するために必要な複雑さとビジネスロジックの理解のレベルが高まります。

BOLA の対象であるからといって、BOPLA の対象でもあるわけではありません。また、一括割り当てと過剰なデータ公開を 1 つのカテゴリに統合することで、オブジェクト内の属性に必要な注意が強調されます。

この区別は、API セキュリティ製品を選択する CISO にとって重要です。製品が両方の種類の攻撃に対応していることを確認する必要があるためです。

API6: 2023 サーバー側リクエストフォージェリが追加され、API8: 2019 インジェクションが削除されました

OWASP コミュニティは、インジェクションの重大度を下げ、サーバー側リクエスト偽造 (SSRF) を追加しました。これは、マネージドセキュリティサービスプロバイダーを取り巻く環境の変化と、セキュリティ製品がすぐに脅威に対応できることに対する期待の変化を物語る大胆な動きです。この変更により、別の攻撃ベクトルの詳細も TOP 10 に提供されるようになります。

OWASP コミュニティがこの変更を選択した理由として、次のようなものが挙げられます。

クラウドでは、Kubernetes と Docker は API を介して URL を渡すため、インジェクションよりも SSRF に対して脆弱な API が多くなる可能性があります。
一般的なサービス (SaaS、PaaS、CloudaaS など) を使用すると、必須サービス (SSO や OAuth 2.0 など) よりも URL が公開される可能性が高くなり、リダイレクトされる可能性が高くなります。
インジェクションは、API7:2023 セキュリティの誤った構成の本質的な一部となっています。
適切なセキュリティ構成には、Web アプリケーションファイアウォールが含まれており、デフォルトでインジェクションを防ぐ必要があります。

API8:2023 自動化された脅威に対する保護の欠如がトップ10に新たに登場

OWASP は、レート制限防御は時間の経過とともに効果が低下し、実装上の欠陥やその他の脆弱性がない限り、ボットは API を意図したとおりに使用して自動的に企業に損害を与える可能性があると警告しています。詳細については、OWASP Automated Threats to Web Applications を参照してください。これは、API に関する独自の視点を提供するものではなく、一般的なアプローチをとっています。

このサプリメントについて知っておくべきことは次のとおりです。

自動化された脅威は防御を突破し、より高度化しています。
API は大規模なサービスの提供を目的としているため、重点的に扱われます。
自動化された脅威防御レイヤーでは、API だけでなくすべてのビジネスロジックを監視する必要があります。

API10:2023 APIの安全でない使用もTOP10に新たに登場

aaS 製品の急速な発展により、API はさまざまな内部および外部 (サードパーティ) サービスと統合して通信し、データを送受信する必要が生じることがよくあります。このような状況では「基本的な」セキュリティルールに従うことも重要であり、この領域ではセキュリティ製品の検出や積極的な防御が複雑になる可能性があります。

OWASP のドキュメントには、次のような一般的な推奨事項と API 固有の推奨事項の両方が含まれています。

リダイレクトに注意深く従ってください。
この監視をビジネスロジックに組み込む
トラフィックを検査/監視/チェックするセキュリティ製品を導入する
サードパーティの API は通常は有料サービスですが (推奨エンジンや検索エンジンなど)、信頼しないでください。
アプリケーションに防御と制限を組み込む

最終的な洞察とポイント

新しい OWASP API セキュリティトップ 10 リリース候補は、アプリケーション中心のトップ 10 から逸脱し、API 脅威の固有の性質を強調した、API 固有の方向への重要なステップです。

覚えておくべき重要なポイントは次のとおりです。

API を保護するのは困難です。攻撃は複雑で、顧客固有のものである可能性があり、API 内のビジネスロジックに関する知識が必要になる場合があります。したがって、セキュリティ製品では、API を適切に保護するために、より高いコンピューティング能力が必要になる場合があります。
OWASP は、API セキュリティの分野でいくつかの新しいトピックを強調しています。
第三者や内部サービスは信頼できない
クラウド環境、コンテナ、Kubernetes は API セキュリティ (高レベル) の一部として含まれており、URL 配信の高リスク (SSRF) に役割を果たします。
「認証」は、API 攻撃のトピックの上位 5 つのうち 4 つを占めています。これは、API 認証の複雑さと、ソフトウェアの問題ではなく API ロジックの欠陥によって生じる脆弱性をテストして特定することの難しさを浮き彫りにします。