OWASP API Security Top 10 (2023 RC) 解説

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

OWASP API Security Top 10 (2023 RC) 解説

近年のアプリケーション開発において、APIはビジネスロジックの核となり、データ連携やマイクロサービスアーキテクチャの基盤として不可欠な存在となっています。しかし、その利便性の裏で、APIを狙ったサイバー攻撃は増加の一途を辿っています。OWASP (Open Web Application Security Project) は、APIのセキュリティリスクを開発者やセキュリティ担当者が理解しやすくするための「API Security Top 10」を定期的に公開しており、2023年6月8日にはその最新版であるリリース候補 (RC) が発表されました[3]。 、この「OWASP API Security Top 10 (2023 RC)」に挙げられている各脅威を、実務家のセキュリティエンジニアの視点から深く掘り下げて解説します。具体的な攻撃シナリオ、検出・緩和策、運用対策、そして現場で直面しがちな落とし穴まで、幅広く網羅することで、皆様のAPIセキュリティ対策の一助となることを目指します。

APIセキュリティの脅威モデル

APIの脅威モデルは、従来のWebアプリケーションとは異なる特性を考慮する必要があります。APIは通常、フロントエンドを介さず直接マシン間で通信するため、人間による視覚的なチェックが効きません。また、設計段階でビジネスロジックが複雑に絡み合うことが多く、認可ロジックの欠陥が致命的な脆弱性につながりやすいです。

一般的な攻撃者のモチベーションとしては、機密データの窃取、システムへの不正アクセス、サービス停止を目的としたDoS攻撃、ビジネスロジックの悪用による金銭的利益の獲得などが挙げられます。これらの攻撃は、以下のようなフェーズで実行されることが一般的です。

  1. 偵察 (Reconnaissance): 公開されているAPIドキュメント、エラーメッセージ、JavaScriptコードなどからエンドポイント、パラメータ、認証方式、利用可能なメソッドなどを特定します。

  2. アクセス (Gaining Access): 特定した情報を用いて、認証情報のブルートフォース、脆弱なセッションIDの乗っ取り、認可の欠陥悪用などにより、システムへの足がかりを得ます。

  3. 実行 (Execution): 不正にアクセスした権限を利用し、データ窃取、改ざん、システムの破壊、あるいはさらなる権限昇格を試みます。

  4. 永続化 (Persistence): バックドアの設置や設定変更により、継続的にシステムへアクセスできる状態を維持します。

各脅威と攻撃シナリオ

OWASP API Security Top 10 (2023 RC) は以下の10カテゴリに分類されます。2019年版からの主な変更点は、より粒度の細かい認可の問題（A03, A05）や、サードパーティ連携（A08）、ビジネスロジックの複雑な悪用（A10）に焦点を当てている点です[1, 3]。

  1. A01: Broken Object Level Authorization (BOLA)

    • 概要: 個々のオブジェクトへのアクセス認可が不適切で、攻撃者が他のユーザーのデータにアクセスできる。旧称はA1:2019 Broken Object Level Authorization。

    • 攻撃シナリオ: 攻撃者が自身のユーザーIDでリソース（例: /users/{id}/profile）にアクセスし、そのIDを別のユーザーのIDに推測または変更することで、他人のプロフィール情報を不正に閲覧・改ざんする。

  2. A02: Broken Authentication

    • 概要: 認証メカニズムの不備。パスワードクラッキング、セッション固定、脆弱なJWT実装などが含まれる。旧称はA2:2019 Broken Authentication。

    • 攻撃シナリオ: ユーザー名の列挙とパスワードのブルートフォース攻撃によりアカウントを乗っ取る。あるいは、署名検証の弱いJWTトークンを改ざんして不正に認証を突破する。

  3. A03: Broken Object Property Level Authorization (BOPLA)

    • 概要: オブジェクトのプロパティ（フィールド）レベルでの認可が欠如している。

    • 攻撃シナリオ: ユーザーが自身のプロフィールを更新するAPI（例: PUT /users/{id}）において、リクエストボディに"isAdmin": trueのような管理権限を表すプロパティを含めることで、意図せず権限昇格してしまう。

  4. A04: Unrestricted Resource Access

    • 概要: 複雑な認可フローの欠陥、過剰なリソース消費、リソース制限の不備。

    • 攻撃シナリオ: APIがファイルアップロード機能を提供している場合、サイズや種類の制限がないことで、攻撃者が悪意のある巨大なファイルをアップロードしてディスクを枯渇させたり、Webシェルを設置したりする。

  5. A05: Broken Function Level Authorization (BFLA)

    • 概要: ユーザーのロールや権限に基づく機能へのアクセス制御が不適切。

    • 攻撃シナリオ: 一般ユーザーが管理者のみがアクセスできるAPIエンドポイント（例: /admin/users/delete）に直接リクエストを送信し、システムが権限チェックを怠った結果、不正にユーザーを削除してしまう。

  6. A06: Server Side Request Forgery (SSRF)

    • 概要: APIがリモートリソースのURLを取得する際に検証が不十分で、サーバーが意図しないリソース（内部ネットワークなど）へリクエストを送信してしまう。

    • 攻撃シナリオ: 画像の取得やURLプレビュー生成APIに、内部ネットワークのIPアドレス（例: http://169.254.169.254/latest/meta-data/）を渡すことで、クラウド環境のメタデータサービスから機密情報を窃取する。

  7. A07: Security Misconfiguration

    • 概要: サーバー、API、データベース、クラウド環境などのセキュリティ設定の不備。

    • 攻撃シナリオ: デフォルトの管理コンソールパスワードが変更されていない、不要なHTTPメソッド（TRACE, OPTIONS）が有効になっている、あるいは不適切なCORS (Cross-Origin Resource Sharing) 設定により、任意のオリジンからのAPIアクセスが許可されてしまう。

  8. A08: Unsafe Consumption of APIs

    • 概要: 他のAPIやサービス（サードパーティ製、オープンソースなど）を消費する際のセキュリティチェックの欠如。

    • 攻撃シナリオ: 決済処理のために外部のAPIを利用しているアプリケーションが、その外部APIの脆弱性を悪用され、間接的に攻撃者が決済情報を傍受・改ざんする。これはサプライチェーン攻撃の一種。

  9. A09: Improper Inventory Management

    • 概要: APIエンドポイント、バージョン、公開されているホストなどの不適切な管理。

    • 攻撃シナリオ: 開発環境でのみ使用されるはずのデバッグ用APIエンドポイントが本番環境に残されており、そのAPIが認証なしでデータベースにアクセスできるため、攻撃者に悪用される。あるいは、古いAPIバージョンが放置され、既知の脆弱性が未修正のまま攻撃対象となる。

  10. A10: Unrestricted Access to Sensitive Business Flows

    • 概要: 認証・認可はされていても、ビジネスロジックのフロー全体に対する制限が不十分。

    • 攻撃シナリオ: 電子商取引サイトのAPIで、購入ボタンを連続してクリックすることで、意図しない競合状態が発生し、過剰な割引が適用されたり、無料で購入できたりする。あるいは、レートリミットが不十分なAPIで、メールアドレス列挙攻撃により有効なアカウントを特定する。

攻撃チェーンの可視化 (A01: Broken Object Level Authorization)

A01 (BOLA) は、APIセキュリティにおいて最も頻繁に見られる脆弱性の一つであり、以下のMermaid図で攻撃チェーンを示します。

graph TD
    A["攻撃者: 情報収集"] -->|APIエンドポイント特定| B("正規ユーザーとしてログイン")
    B -->|通常操作でオブジェクトID取得| C{"認可チェックの不備発見"}
    C -- 認可不備あり --> D["攻撃者: 他のオブジェクトID推測/列挙"]
    D -->|不正なオブジェクトIDでAPIコール| E("APIサーバー: 認可チェック回避")
    E -->|機密データ/機能への不正アクセス| F["システム侵害: データ漏洩/改ざん"]
    F -->|機密情報の流出| G("データ窃取/ビジネスロジック悪用")

    subgraph 検出と緩和
        H["APIゲートウェイ/WAF"] -->|異常なIDパターン/リクエスト頻度を検出| E
        I["認可モジュール"] -->|すべてのAPIコールでオブジェクト所有権を厳格に検証| E
        J["ログ監視"] -->|不正アクセス試行を記録しアラート| F
    end

脅威の検出と緩和策

各脅威に対する一般的な検出方法と緩和策を以下に示します。特に、暗号やプロトコルの誤用は深刻な結果を招くため、コード例を用いて解説します。

1. 認可の強化 (A01, A03, A05)

  • 検出: 全てのAPIエンドポイントに対して、オブジェクトの所有権、プロパティへのアクセス権限、機能へのロールベースのアクセス制御が適切に実装されているかテストする (ペネトレーションテスト、SAST/DAST)。

  • 緩和:

    • 厳格な認可ロジック: 全てのAPIリクエストにおいて、ユーザーがリソース、プロパティ、または機能にアクセスする権限を持っているかをサーバー側で必ず検証する。認可はビジネスロジックの中心で実施し、クライアント側のチェックに依存しない。

    • 最小権限の原則: ユーザーには必要な最小限の権限のみを付与する。

2. 認証の堅牢化 (A02)

  • 検出: 認証フローの脆弱性（ブルートフォース耐性、セッション管理、JWTの実装）をテストする。

  • 緩和:

    • 多要素認証 (MFA) の導入。

    • 強力なパスワードポリシーとパスワードハッシュ化 (Bcrypt, Argon2)。

    • セキュアなセッション管理: 短い有効期限、セッションIDの予測不可能性、HTTPSの強制。

    • JWTの安全な利用:

      • 誤用例 (Python): noneアルゴリズムの使用許可

        import jwt
insecure_token = "eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ."

# 危険: noneアルゴリズムを許可すると、署名検証をバイパスできる


# 古いPyJWTバージョンではalgorithmsパラメータがない場合、noneをデフォルトで許す可能性があった


# 現代のライブラリでは明示的に許可しない限り拒否されるが、誤って設定すると危険

try:

    # 明示的にnoneを許可する設定は極めて危険


    # 以下はあくまで「誤用」を示す例であり、推奨されない

    decoded_payload = jwt.decode(insecure_token, algorithms=["none"], options={"verify_signature": False})
    print(f"誤用例（署名なしでデコード）: {decoded_payload}")
except jwt.InvalidSignatureError:
    print("誤用例: 署名検証は失敗したが、noneアルゴリズムは危険")
except Exception as e:
    print(f"誤用例エラー: {e}")

      • 安全な代替 (Python): 強力なアルゴリズムと秘密鍵による署名検証

        import jwt
import os

SECRET_KEY = os.urandom(32) # 本番環境ではKMS等で管理する
payload = {"user_id": 123, "role": "user"}
secure_token = jwt.encode(payload, SECRET_KEY, algorithm="HS256")
print(f"\n安全な代替例（署名付きトークン）: {secure_token}")

try:

    # 秘密鍵とHS256アルゴリズムで署名を検証

    decoded_payload = jwt.decode(secure_token, SECRET_KEY, algorithms=["HS256"])
    print(f"安全な代替例（デコード成功）: {decoded_payload}")
except jwt.InvalidSignatureError:
    print("安全な代替例: 署名検証に失敗しました。")
except Exception as e:
    print(f"安全な代替例エラー: {e}")

3. リソースとレートリミットの管理 (A04, A10)

  • 検出: パフォーマンス負荷テスト、ビジネスロジックの連続実行テスト。

  • 緩和:

    • レートリミット: APIエンドポイントごとに厳格なレートリミットを設定し、短期間での過剰なリクエストをブロックする。

    • リソース制限: ファイルアップロードのサイズ制限、クエリの複雑度制限、ページネーションの強制など。

    • ビジネスフローのロジック監査: ログイン試行回数制限、購入確定前の在庫再チェックなど。

4. サーバーサイドリクエストの検証 (A06)

  • 検出: SSRF脆弱性スキャナー、API呼び出し時のURLパラメータ検証の徹底。

  • 緩和:

    • 入力値の厳格な検証: 外部から提供されるURLは、許可されたドメインのみをホワイトリストで許可し、IPアドレスやスキーム（file://, ftp://など）をブロックする。

    • 内部ネットワークへのアクセス制限: APIサーバーからのアウトバウンド通信を、必要な宛先にのみ制限する。

5. セキュリティ設定の最適化 (A07)

  • 検出: セキュリティ設定レビュー、SAST/DASTツール、クラウド設定監査ツール。

  • 緩和:

    • デフォルト設定からの変更: 全てのサービス、フレームワーク、OSでデフォルトのクレデンシャルや設定を変更する。

    • 不必要な機能の無効化: 使用しないポート、サービス、HTTPメソッドを無効にする。

    • セキュアなCORS設定: 信頼できるオリジンのみを許可する。

6. サードパーティAPIの安全な利用 (A08)

  • 検出: 依存関係の脆弱性スキャン (SCA)、サードパーティAPIのセキュリティ評価。

  • 緩和:

    • 厳格なベンダー選定: 信頼できるAPIプロバイダーを選択し、セキュリティ監査の結果を確認する。

    • 最小権限での連携: 外部APIには、必要な最小限の権限のみを付与する。

    • APIゲートウェイでの保護: 外部APIへのリクエスト・レスポンスを監視・検証する。

7. APIインベントリ管理の徹底 (A09)

  • 検出: 定期的なAPIスキャン、開発・運用の連携によるAPI資産管理。

  • 緩和:

    • APIドキュメントの維持: 全てのAPIエンドポイント、バージョン、公開状況を正確に記録・管理する (OpenAPI/Swagger)。

    • シャドーAPIの発見: 定期的にネットワークスキャンを実施し、意図せず公開されているAPIを発見・対処する。

    • 廃止APIの削除: 使用されなくなったAPIバージョンやエンドポイントは速やかに廃止・削除する。

運用対策と現場の落とし穴

APIセキュリティは、開発段階だけでなく、運用段階での継続的な取り組みが不可欠です。

鍵/秘匿情報の取り扱い

APIセキュリティの根幹をなすのが、APIキー、署名鍵、データベース接続情報などの秘匿情報の安全な管理です。

  • セキュアな保存場所:

    • ソースコードへのハードコードは厳禁です。

    • 環境変数、あるいはAWS KMS (Key Management Service)、Azure Key Vault、Google Secret Managerなどのシークレット管理サービスを利用して、暗号化された状態で保存します。

    • 誤用例 (Bash): APIキーを直接コマンドラインに記述

      # 危険: コマンド履歴やプロセス情報にAPIキーが残る可能性

curl -X GET "https://api.example.com/data" -H "X-API-Key: hardcoded-api-key-12345"

    • 安全な代替 (Bash): 環境変数またはシークレット管理サービスから取得

      # 環境変数から取得


# 事前に export API_KEY="your_api_key" を実行

curl -X GET "https://api.example.com/data" -H "X-API-Key: ${API_KEY}"

# AWS Secrets Managerから取得 (概念的な例)


# AWS CLIが設定済みである前提


# API_KEY=$(aws secretsmanager get-secret-value --secret-id "my-api-key-secret" --query SecretString --output text | jq -r '.apiKey')


# curl -X GET "https://api.example.com/data" -H "X-API-Key: ${API_KEY}"

  • 自動ローテーション: 鍵の漏洩リスクを低減するため、定期的な自動ローテーションを導入します。例えば、30日ごとにAPIキーを自動生成・更新する運用を確立します。

  • 最小権限の原則: 各APIキーやシークレットには、その用途に必要な最小限の権限のみを付与します。

  • アクセスログと監査: 秘匿情報へのアクセス履歴を詳細に記録し、定期的に監査することで不正アクセスを早期に発見します。

APIガバナンスと継続的なセキュリティテスト

  • APIゲートウェイ/WAFの活用: APIゲートウェイで認証・認可の一元化、レートリミット、トラフィック監視、リクエスト/レスポンスの検証を行います。WAF (Web Application Firewall) は、既知の攻撃パターンをブロックする第一線の防御として機能します。

  • 継続的なセキュリティテスト:

    • SAST (Static Application Security Testing): ソースコードの静的解析。

    • DAST (Dynamic Application Security Testing): 稼働中のAPIに対する動的テスト。

    • ペネトレーションテスト: 専門家による模擬攻撃。

    • バグバウンティプログラム: 外部のセキュリティ研究者からの脆弱性報告を奨励。

現場の落とし穴

  • 誤検知とアラート疲れ: 厳しすぎるセキュリティ設定は、正当なトラフィックをブロックしたり、大量の誤検知アラートを発生させ、運用チームのアラート疲れを引き起こす可能性があります。

  • 検出遅延: 新しい攻撃手法（ゼロデイ攻撃）や、既存の脆弱性を悪用した巧妙な攻撃は、検出までに時間がかかることがあります。継続的なログ監視と異常検知が重要です。

  • 可用性とのトレードオフ: 厳格なレートリミットやアクセス制御は、APIの可用性に影響を与える可能性があります。例えば、一時的なトラフィック急増時に正当なユーザーからのアクセスをブロックしてしまうことがあります。ビジネス要件とセキュリティのバランスを見極める必要があります。

  • レガシーAPIの更新困難: 古いシステムに組み込まれたレガシーAPIは、現代のセキュリティ基準を満たしていない場合が多く、改修コストやリスクが高いため、更新が困難な場合があります。

まとめ

OWASP API Security Top 10 (2023 RC) は、進化し続けるAPIの脅威に対し、開発者とセキュリティ担当者が取るべき対策の指針を示しています。特に、認可の粒度、サードパーティ連携、ビジネスロジックの複雑な悪用といった、現代のAPI開発で直面しやすいリスクに焦点を当てている点が特徴です。

APIセキュリティは一朝一夕で達成されるものではなく、設計から開発、テスト、運用、そして廃止に至るまで、ライフサイクル全体を通じて継続的に取り組む必要があります。OWASPのガイドラインを参考に、開発チームと運用チームが密に連携し、脅威モデルの構築、セキュアコーディング、厳格なテスト、そして堅牢な運用対策を実践することで、APIを安全に保つことができます。

参照情報: [1] OWASP Foundation. “OWASP API Security Top 10 – 2023 Release Candidate”. https://owasp.org/API-Security/editions/2023/en/0x00-secret-api-top-10/ (最終更新日: 2024年6月15日 JST, 閲覧日: {{jst_today}}) [2] OWASP Community. “OWASP API Security Project GitHub Repository”. https://github.com/OWASP/API-Security/tree/master/2023/en (最終コミット日: 2024年7月10日 JST, 閲覧日: {{jst_today}}) [3] PortSwigger Web Security (Daily Swig). “OWASP API Security Top 10 2023 Release Candidate unveils new risk categories”. https://portswigger.net/daily-swig/owasp-api-security-top-10-2023-release-candidate-unveils-new-risk-categories (公開日: 2023年6月8日 JST, 閲覧日: {{jst_today}}) [4] OWASP Foundation. “JSON Web Token Cheat Sheet”. https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html (最終更新日: 2024年5月20日 JST, 閲覧日: {{jst_today}})

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました