OWASP API Security Top 10 2023対策：実務家のための実践ガイド

Tech

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

OWASP API Security Top 10 2023対策：実務家のための実践ガイド

脅威モデルの構築

APIセキュリティにおける脅威モデルは、APIが直面しうるリスクを特定し、優先順位を付けるための基盤です。STRIDEやDREADなどのフレームワークを活用し、開発ライフサイクルの早期段階で実施することが推奨されます。

  • STRIDEモデル

    • Spoofing（なりすまし）

    • Tampering（改ざん）

    • Repudiation（否認）

    • Information Disclosure（情報漏洩）

    • Denial of Service（サービス拒否）

    • Elevation of Privilege（権限昇格）

OWASP API Security Top 10 2023の概要

OWASP API Security Top 10 2023は、APIに特化した最も一般的な脆弱性をリストアップしたものです。これを脅威モデルの脅威リストとして活用することで、特定の脆弱性に対する対策を体系的に検討できます[1]。

  1. API1:2023 Broken Object Level Authorization (BOLA): 認可の欠陥により、他のユーザーのオブジェクトにアクセス可能。

  2. API2:2023 Broken Authentication: 不適切な認証実装によるアカウント乗っ取り。

  3. API3:2023 Broken Object Property Level Authorization (BOPLA): オブジェクトのプロパティレベルでの認可の欠陥。

  4. API4:2023 Unrestricted Resource Consumption: 悪意のあるリソース消費によるDoS攻撃やコスト増加。

  5. API5:2023 Broken Function Level Authorization (BFLA): ユーザーのロールに応じた機能へのアクセス制御の欠陥。

  6. API6:2023 Unrestricted Access to Sensitive Business Flows: ビジネスロジックを悪用した攻撃。

  7. API7:2023 Server Side Request Forgery (SSRF): APIが内部リソースにアクセスする機能の悪用。

  8. API8:2023 Security Misconfiguration: デフォルト設定、不要な機能、不適切なHTTPヘッダーなど。

  9. API9:2023 Improper Inventory Management: 古いAPIバージョン、公開されたデバッグエンドポイントなど。

  10. API10:2023 Unsafe Consumption of APIs: 外部APIを利用する際のセキュリティ欠陥。

攻撃シナリオと典型的な攻撃チェーン

OWASP API Security Top 10 2023の各項目は、具体的な攻撃シナリオに落とし込むことで、より詳細な対策を検討できます。ここでは、API1:2023 Broken Object Level Authorization (BOLA)とAPI2:2023 Broken Authenticationを例に攻撃チェーンを示します。

graph TD
    A["攻撃者: APIエンドポイントを探索"] --> |パラメータ推測/辞書攻撃| B["標的APIの特定"]
    B --> |認可トークンAでオブジェクトIDを置換| C["リクエスト送信: GET /users/{other_user_id}"]
    C -- 認可チェックの欠陥 --> D["APIサーバー: 他のユーザーのデータを返す"]
    D --> E["攻撃者: 認証・認可なしにデータ取得成功"]
    E -- API1:2023 BOLAの悪用 --> F["大規模な情報漏洩"]

    subgraph Broken Authentication Attack
        G["攻撃者: 脆弱な認証メカニズムを特定"] --> |ブルートフォース/クレデンシャルスタッフィング| H["ユーザー名とパスワードの推測"]
        H --> I["ログインリクエスト送信: POST /login"]
        I -- 不適切なレート制限/ロックアウトポリシー --> J["APIサーバー: 認証情報の検証"]
        J -- 認証成功 --> K["攻撃者: 有効なセッショントークン取得"]
        K -- API2:2023 Broken Authenticationの悪用 --> L["アカウント乗っ取り"]
    end

説明:

  • BOLA攻撃チェーン: 攻撃者はAPIエンドポイントを探索し、オブジェクトIDの推測や辞書攻撃によって、アクセス権限のないリソースへのアクセスを試みます。サーバー側の認可チェックが不十分な場合、攻撃者は他のユーザーの機微なデータを不正に取得できてしまいます。

  • Broken Authentication攻撃チェーン: 攻撃者は、ユーザー名とパスワードの推測（ブルートフォース攻撃やクレデンシャルスタッフィング）を繰り返し行います。APIが不適切なレート制限やアカウントロックアウトポリシーを適用している場合、最終的に認証情報を突破し、有効なセッショントークンを取得してアカウントを乗っ取ります。

検出と緩和策

1. API1:2023 Broken Object Level Authorization (BOLA) / API3:2023 Broken Object Property Level Authorization (BOPLA) / API5:2023 Broken Function Level Authorization (BFLA)

  • 検出:

    • セキュリティテスト（ペネトレーションテスト、動的アプリケーションセキュリティテスト (DAST)）。

    • APIゲートウェイやWAFのログ監視による異常なアクセスパターン（例: 特定のユーザーによる頻繁な異なるオブジェクトIDへのアクセス）。

  • 緩和:

    • 厳格な認可チェック: 全てのAPIエンドポイントで、リクエストされたオブジェクト/プロパティ/機能に対するユーザーの権限をサーバー側で厳密に検証します。認可ロジックはポリシー決定ポイント（PDP）とポリシー適用ポイント（PEP）に分離し、一貫性を保ちます[2]。

    • UUIDやハッシュ化されたIDの使用: 推測されにくいユニークなIDを使用し、連番IDを避けることで、推測によるアクセスを困難にします。

    • Open Policy Agent (OPA) などの認可ポリシーエンジンを導入し、認可ロジックを一元管理・検証する。

2. API2:2023 Broken Authentication

  • 検出:

    • 認証失敗ログの監視。異常なログイン試行回数、短時間での多IPアドレスからのアクセス。

    • WAFやAPIゲートウェイによるブルートフォース/クレデンシャルスタッフィング検知。

  • 緩和:

    • 強力なパスワードポリシー: 長さ、複雑性、履歴制限を強制。

    • 多要素認証 (MFA) の義務化。

    • レートリミット: 認証エンドポイントへの試行回数を制限し、ブルートフォース攻撃を遅延させます。例: 1分間に5回以上の試行でIPを一時的にブロック。

    • アカウントロックアウト: 複数回の認証失敗後にアカウントを一時的にロックアウト。

    • セッショントークンの管理: 短い有効期限、HTTP Onlyフラグ、Secureフラグの使用。

    誤用例 (セッショントークンの不適切な扱い)

    // クライアントサイドでのセッショントークン保存（XSSで窃取されやすい）
localStorage.setItem('session_token', response.token);

    安全な代替 (セッショントークンの安全な扱い)

    // サーバー側で発行されたセッショントークンをHttpOnly, Secureクッキーで設定
// サーバーサイド（例: Node.js Express）
res.cookie('session_token', token, {
    httpOnly: true, // JavaScriptからのアクセスを禁止
    secure: true,   // HTTPSのみで送信
    sameSite: 'Lax', // CSRF対策
    expires: new Date(Date.now() + 3600000) // 1時間後に期限切れ
});

3. API4:2023 Unrestricted Resource Consumption

  • 検出:

    • APIゲートウェイや監視ツールによるAPI使用状況（リクエスト数、データ量、CPU/メモリ使用量）の異常検知。

    • DoS攻撃検知システム。

  • 緩和:

    • レートリミット: ユーザー、IPアドレス、APIキーごとにリクエスト数を制限。

    • ペイロードサイズの制限: APIが受け付けるリクエストボディの最大サイズを制限。

    • クエリの複雑性制限: GraphQLなどのAPIでは、クエリの深さやコストを制限。

    • スロットリング: 短時間に大量のリクエストを送信するユーザーを一時的に制限。

4. API7:2023 Server Side Request Forgery (SSRF)

  • 検出:

    • ネットワークトラフィック監視による異常な外部/内部アクセス。

    • WAFによるSSRFシグネチャ検知。

  • 緩和:

    • 入力検証: ユーザーが提供するURLやリソース指定を厳密に検証し、ホワイトリスト方式で許可されたドメインやプロトコルのみを許可する。

    • 内部ネットワークへのアクセス制限: APIが外部の入力に基づいて内部リソースにアクセスできないよう、ネットワークレベルで制限をかける（ファイアウォールルール）。

    • 最小権限の原則: 内部リソースへのアクセスが必要な場合でも、そのAPIが必要とする最低限の権限のみを付与する。

    • メタデータサービスへのアクセス制限: クラウド環境では、EC2のメタデータサービスなどへのアクセスをブロックまたは厳しく制限する。

5. API8:2023 Security Misconfiguration

  • 検出:

    • セキュリティ設定の定期的な監査。

    • 自動化された設定スキャンツール。

  • 緩和:

    • セキュアなデフォルト設定: 全てのコンポーネントで出荷時のデフォルト設定をレビューし、セキュアなものに変更。

    • 不要な機能の無効化: 使用しないポート、サービス、デバッグ機能、エンドポイントを無効化。

    • 最小権限の原則: 各サービス、ユーザーに必要最小限の権限のみを付与。

    • HTTPセキュリティヘッダー: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options などを適切に設定。

    誤用例 (不適切なCORS設定)

    # 全てのオリジンからのアクセスを許可（セキュリティリスク）

add_header Access-Control-Allow-Origin "*";

    安全な代替 (CORSの安全な設定)

    # 許可されたオリジンのみからのアクセスを許可

location /api {
    if ($http_origin ~* "^(https?://(www\.example\.com|api\.example\.com))$") {
        add_header Access-Control-Allow-Origin "$http_origin";
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization";
        add_header Access-Control-Allow-Credentials "true";
        add_header Access-Control-Max-Age 1728000;
    }

    # OPTIONSリクエストの処理

    if ($request_method = 'OPTIONS') {
        add_header Content-Length 0;
        return 204;
    }
    proxy_pass http://backend_api;
}

運用対策

1. 鍵/秘匿情報の取り扱い

APIキー、OAuthクライアントシークレット、データベースパスワードなどの秘匿情報は、以下の原則に従って管理します。

  • 鍵管理システム (KMS) の活用: AWS KMS, Azure Key Vault, Google Cloud KMS などの専用サービスを利用して、鍵の生成、保存、アクセス制御、ローテーションを一元管理します[3][4]。

  • 環境変数やシークレット管理サービスの使用: コード内に直接ハードコーディングせず、環境変数やKubernetes Secrets、HashiCorp Vaultなどのシークレット管理サービスを通じて提供します。

    • 誤用例 (コードに秘匿情報を直接記述)

      # 絶対にやってはいけない

API_KEY = "sk_live_XXXXXXXXXXXXXXXXXXXX"
DB_PASSWORD = "my_super_secret_password"

    • 安全な代替 (環境変数から取得)

      import os

API_KEY = os.getenv("MY_SERVICE_API_KEY") # 環境変数からAPIキーを取得
DB_PASSWORD = os.getenv("DB_PASSWORD")   # 環境変数からDBパスワードを取得
if not API_KEY or not DB_PASSWORD:
    raise ValueError("API_KEY or DB_PASSWORD environment variable not set.")

# ... API呼び出しやDB接続


# 前提: 環境変数 MY_SERVICE_API_KEY と DB_PASSWORD が設定されていること


# 計算量: O(1)


# メモリ条件: 環境変数を読み込むためのわずかなメモリ

  • 最小権限の原則: 鍵やシークレットへのアクセスは、その情報を必要とする最小限のサービスやユーザーに限定します。IAMポリシーなどを活用します。

  • 定期的なローテーション: 鍵の有効期限を設定し、定期的に（例: 90日ごと）自動または手動でローテーションします。漏洩時の被害を最小限に抑えます。

  • 監査ログ: 鍵へのアクセス、使用、ローテーションに関する全ての操作をログに記録し、不正アクセスがないか定期的に監査します。

2. プロトコルの安全な利用

OAuth 2.0やOpenID Connect (OIDC) などのプロトコルは複雑であり、誤った実装は深刻な脆弱性につながります。

  • 認可コードフロー + PKCE の使用: Webアプリケーションやモバイルアプリケーションでは、Public Client向けの認可コードフローとProof Key for Code Exchange (PKCE) の組み合わせが最も安全とされています[5]。Implicit GrantやResource Owner Password Credentials Grantは非推奨です。

    • 誤用例 (Implicit Grant)

      GET /authorize?response_type=token&client_id=...&redirect_uri=...&scope=...

# アクセストークンがURLフラグメントで返されるため、ブラウザ履歴やリファラで漏洩リスクあり

    • 安全な代替 (認可コードフロー + PKCE)

      # 1. クライアントがcode_verifierを生成し、code_challengeを計算


# 2. 認可リクエスト

GET /authorize?response_type=code&client_id=...&redirect_uri=...&scope=...&code_challenge=...&code_challenge_method=S256

# 3. ユーザー認可後、認可コードがリダイレクトURIに返される


# 4. クライアントがトークンリクエスト（サーバーサイドで実行）

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=...&redirect_uri=...&client_id=...&code_verifier=...

# アクセストークンはサーバー間通信で安全に取得される


# 前提: クライアントと認可サーバーがOAuth 2.0認可コードフロー+PKCEに対応していること


# 入力: client_id, redirect_uri, code, code_verifier


# 出力: アクセストークン、リフレッシュトークン（オプション）


# 計算量: トークン発行サーバーの負荷に依存。PKCE計算はクライアント側でO(1)


# メモリ条件: 認証情報、トークンの一時的な保持

  • 常にHTTPSを使用: API通信の機密性と完全性を保護するため、全ての通信でTLS (HTTPS) を強制します。

  • 適切なスコープの適用: API利用者に必要最小限の権限（スコープ）のみを付与し、過剰な権限付与を避けます。

3. 監査とログ管理

  • 詳細なログ収集: 全てのAPIリクエスト/レスポンス、認証、認可イベント、エラー、システム変更などを詳細にログに記録します。ユーザーID、タイムスタンプ、IPアドレス、リクエストパス、ステータスコードを含める。

  • 一元的なログ管理: Splunk, ELK Stack, Datadogなどのログ管理システムに集約し、リアルタイムでの監視と分析を可能にします。

  • 定期的なログレビューとアラート: 異常なパターン（例: 認証失敗の急増、認可エラーの多発、未定義エンドポイントへのアクセス）を検知するアラートを設定し、セキュリティチームがレビューします。

4. 現場の落とし穴

  • 誤検知（False Positive）: 厳格すぎるWAFルールやレートリミットは、正規のユーザーや連携サービスからのアクセスを誤ってブロックし、可用性を損なう可能性があります。ルールの調整と例外設定が重要です。

  • 検出遅延: 異常検知からインシデント対応までのタイムラグは、攻撃被害を拡大させます。リアルタイム監視と自動化された対応（例: 不審IPのブロック）の導入が不可欠です。

  • 可用性とのトレードオフ: セキュリティ対策の強化は、APIのパフォーマンスや開発速度に影響を与えることがあります。セキュリティと可用性/利便性のバランスを考慮し、リスク評価に基づいて優先順位を決定します。

  • レガシーAPIの放置: 新しいAPIはセキュリティ対策が施されていても、古いAPIバージョンやデバッグ用エンドポイントが放置されることで、そこが攻撃経路となることがあります（API9:2023 Improper Inventory Management）。定期的なAPIインベントリ管理とライフサイクル管理が重要です。

まとめ

OWASP API Security Top 10 2023は、現代のAPIが直面する主要な脅威を理解し、対策を講じるための羅針盤となります。脅威モデリングから始まり、厳格な認可制御、安全な認証メカニズムの確立、リソース消費制限、セキュアな設定、そして鍵管理やプロトコルの安全な利用といった運用対策まで、多層的なアプローチが不可欠です。

特に、現場では誤検知や検出遅延といった課題に直面しがちですが、これらは継続的な監視、チューニング、そしてセキュリティと開発チーム間の密な連携によって克服できます。APIセキュリティは一度行えば終わりではなく、開発ライフサイクル全体にわたる継続的なプロセスであることを認識し、組織全体で取り組むことが成功の鍵となります。

参照: [1] OWASP API Security Top 10 – 2023. OWASP Foundation. (最終アクセス日: 2024-07-30). https://owasp.org/API-Security/editions/2023/ [2] SP 800-207, Zero Trust Architecture. National Institute of Standards and Technology. (最終アクセス日: 2024-07-30). https://csrc.nist.gov/publications/detail/sp/800-207/final [3] Best practices for securely using API keys. Google Cloud documentation. Google Cloud. (最終更新日: 2024-07-26; 最終アクセス日: 2024-07-30). https://cloud.google.com/docs/authentication/api-keys#restricting_api_keys [4] AWS Key Management Service (AWS KMS) Best Practices. Amazon Web Services, Inc. (最終更新日: 2024-07-25; 最終アクセス日: 2024-07-30). https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html [5] RFC 9361 OAuth 2.0 Security Best Current Practice. IETF. (公開日: 2023-09; 最終アクセス日: 2024-07-30). https://www.rfc-editor.org/rfc/rfc9361

脚注

  • JST（日本標準時）: 本記事中の日付はすべてJSTに基づいています。
ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

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