OWASP API Security Top 10 (2023) の脅威と対策

Tech

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

OWASP API Security Top 10 (2023) の脅威と対策

APIは現代のデジタルサービスの基盤であり、そのセキュリティは組織にとって極めて重要です。OWASP API Security Top 10 (2023)は、APIに特化した最も重大なセキュリティリスクをまとめたもので、その理解と対策は実務家のセキュリティエンジニアにとって必須です。本稿では、2023年版の脅威モデル、具体的な攻撃シナリオ、検出・緩和策、そして運用上の注意点について詳述します。

脅威モデル：API固有の脆弱性への焦点

OWASP API Security Top 10 (2023)は、2019年版からの更新を経て、APIに固有の脆弱性により深く焦点を当てています。従来のWebアプリケーション脆弱性リスト（OWASP Top 10）とは異なり、APIのステートレス性、豊富な機能性、広範な連携を悪用する攻撃パターンを強調しています。このリストは、2023年7月11日（JST）に公開され、APIエコシステム全体のセキュリティ向上を目指しています [根拠[1]]。

特に以下のカテゴリが重要視されています。

  • API01:2023 Broken Object Level Authorization (BOLA): 個別のリソースへのアクセス制御の不備。

  • API02:2023 Broken Authentication: 認証メカニズムの脆弱性。

  • API03:2023 Broken Object Property Level Authorization: オブジェクトのプロパティレベルでのアクセス制御の不備。

  • API04:2023 Unrestricted Resource Consumption: 処理リソースの無制限な消費によるサービス妨害。

  • API05:2023 Broken Function Level Authorization (BFLA): 機能レベルでのアクセス制御の不備。

  • API06:2023 Unrestricted Access to Sensitive Business Flows: 重要なビジネスロジックへの無制限アクセス。

  • API07:2023 Server Side Request Forgery (SSRF): APIサーバーからの任意のURLへのリクエスト。

  • API08:2023 Security Misconfiguration: セキュリティ設定の不備。

  • API09:2023 Improper Inventory Management: API資産の不適切な管理。

  • API10:2023 Unsafe Consumption of APIs: 連携するAPIの不適切な利用。

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

ここでは、特に危険度が高いとされる「API01:2023 Broken Object Level Authorization (BOLA)」と「API02:2023 Broken Authentication」に焦点を当て、具体的な攻撃シナリオとその攻撃チェーンを解説します。

API01:2023 Broken Object Level Authorization (BOLA)

BOLAは、APIがユーザーがアクセスできるべきではないオブジェクトにアクセスすることを許してしまう脆弱性です。これは、APIがリクエストされたオブジェクトのID（例えば、user_id=123 や order_id=ABC など）に対して、現在のユーザーがそのオブジェクトにアクセスする権限を持っているかどうかのチェックを適切に行わない場合に発生します。

攻撃シナリオ:

  1. 偵察: 攻撃者は正規ユーザーとしてAPIにログインし、自身のリソース（例: GET /users/me/orders）をリクエストし、その応答からAPIエンドポイントのパターンとオブジェクトIDの形式 (/orders/{order_id}) を把握します。

  2. ID列挙: 攻撃者は、他のユーザーのオブジェクトIDを推測または列挙します（例: order_id を ABC-001 から ABC-002 へ変更）。

  3. 認可バイパス: 攻撃者は、発見した他のユーザーのオブジェクトIDを自身のAPIリクエストに含めて送信します（例: GET /orders/ABC-002）。

  4. データ漏洩/改ざん: APIが適切な権限チェックを行わない場合、攻撃者は他ユーザーの機密情報（注文履歴、個人情報など）を閲覧または改ざんできます。

攻撃チェーン (Mermaid):

graph TD
    A["攻撃者"] -->|正規のAPIエンドポイントを特定 (例: /orders/{order_id})| B("API01: Broken Object Level Authorization")
    B -->|他のユーザーのオブジェクトIDを推測/列挙| C{"認証・認可の不備"}
    C -- 認可チェックをバイパス --> D["他ユーザーの機密データ取得/改ざん"]
    D -->|データ悪用 (詐欺、情報販売など)| E("被害発生")

API02:2023 Broken Authentication

認証メカニズムの欠陥は、攻撃者が正当なユーザーとしてシステムにアクセスすることを可能にします。これには、脆弱な認証情報の利用、認証プロトコルの誤実装、セッション管理の不備などが含まれます。

攻撃シナリオ:

  1. 脆弱な認証情報の悪用:

    • ブルートフォース攻撃: 攻撃者は、ログインAPIエンドポイントに対して、パスワードリスト攻撃や辞書攻撃を実行し、有効なユーザー名とパスワードの組み合わせを特定します。

    • デフォルト認証情報の利用: 攻撃者は、デフォルトのパスワードが変更されていないシステムを探し、容易にログインします。

  2. セッション管理の不備:

    • 予測可能なセッションID: 攻撃者は、セッションIDの生成ロジックを解析し、他のユーザーのセッションIDを推測してセッションハイジャックを行います。

    • セッションの無期限化: ユーザーがログアウトしてもセッションが破棄されない場合、セッションIDを窃取した攻撃者はそのセッションを永続的に利用できます。

検出と緩和策

API01:2023 Broken Object Level Authorization (BOLA) の対策

検出:

  • 詳細なログ記録: APIリクエストの全パラメータ（特にオブジェクトID）、認証情報、そして認可結果を記録します。不正なアクセスパターンや異常なオブジェクトIDの列挙を特定するために、これらのログをSIEM（Security Information and Event Management）ツールで分析します。

  • 動的アプリケーションセキュリティテスト (DAST): 自動化されたツールで、各ユーザーロールから他のユーザーのリソースへのアクセス試行をテストします。

  • 手動ペネトレーションテスト: 実際の攻撃者の視点から、徹底的な認可チェックのバイパス試行を行います。

緩和策:

  • 厳格なオブジェクトレベル認可: すべてのAPIエンドポイントで、リクエストされたオブジェクトに対する現在のユーザーの権限を、バックエンドで厳密にチェックします。クライアントからの入力に依存せず、サーバーサイドでユーザーのセッション情報に基づいて権限を判断します。

    • 安全な実装例 (Python Flask):

      from flask import Flask, request, jsonify, abort

app = Flask(__name__)

# 擬似的なデータベースとユーザーセッション

users_db = {
    "user1": {"id": "1", "name": "Alice"},
    "user2": {"id": "2", "name": "Bob"}
}
orders_db = {
    "order_A": {"user_id": "1", "item": "Laptop"},
    "order_B": {"user_id": "2", "item": "Keyboard"},
    "order_C": {"user_id": "1", "item": "Mouse"}
}

# 擬似的な認証関数

def get_current_user_id(auth_token):

    # 実際にはJWTデコードやDBルックアップなどを行う

    if auth_token == "Bearer user1_token":
        return "1"
    elif auth_token == "Bearer user2_token":
        return "2"
    return None

@app.route("/api/orders/<order_id>", methods=["GET"])
def get_order(order_id):
    """
    API01:2023 Broken Object Level Authorization の安全な代替例。
    オブジェクトIDが直接渡される場合でも、現在のユーザーがそのオブジェクトの
    所有者であるかを厳密に確認する。
    入力: order_id (string) - 取得したい注文のID
          Authorization ヘッダー - ユーザー認証トークン
    出力: JSON形式の注文詳細、またはエラーメッセージ
    前提: 注文データはorders_dbに、ユーザーセッションはget_current_user_idで取得可能。
    計算量: O(1) - 辞書ルックアップと簡単な比較
    メモリ条件: orders_dbのサイズに依存
    """
    auth_header = request.headers.get("Authorization")
    current_user_id = get_current_user_id(auth_header)

    if not current_user_id:
        abort(401, description="認証が必要です。") # 認証されていない

    order = orders_db.get(order_id)
    if not order:
        abort(404, description="注文が見つかりません。")

    # !!! ここが最も重要: 現在のユーザーが注文の所有者かを確認 !!!

    if order["user_id"] != current_user_id:
        abort(403, description="この注文へのアクセス権がありません。") # 認可エラー

    return jsonify(order)

if __name__ == "__main__":

    # テスト例：


    # curl -H "Authorization: Bearer user1_token" http://127.0.0.1:5000/api/orders/order_A  (OK)


    # curl -H "Authorization: Bearer user1_token" http://127.0.0.1:5000/api/orders/order_B  (403 Forbidden)

    app.run(debug=True)

  • GUID/UUIDの使用: 推測が困難なオブジェクトIDを使用することで、ID列挙攻撃の難易度を上げます。ただし、これは認可チェックの代替にはなりません。

API02:2023 Broken Authentication の対策

検出:

  • 異常なログイン試行の監視: 失敗したログイン試行回数、IPアドレスの地理的位置、試行頻度などを監視し、ブルートフォース攻撃やクレデンシャルスタッフィング攻撃を検出します。

  • WAF (Web Application Firewall) / API Gateway: 不正な認証リクエストパターンや過剰な認証試行をブロックします。

  • ログ分析: 認証関連のログを定期的に確認し、異常なアクセス元や不審なセッション活動がないかチェックします。

緩和策:

  • 多要素認証 (MFA) の導入: 認証情報の窃取だけではログインできないように、複数の認証要素を要求します。

  • 強力な認証メカニズム: OAuth 2.0 / OpenID Connect、JWT (JSON Web Tokens) などの標準プロトコルを正しく実装します。

    • JWTの誤用例と安全な代替:

      • 誤用例 (署名検証なし): クライアントから送られてきたJWTの署名を検証せずにペイロードを信用する。

        import jwt

# 危険: algorithm='none' に対応したり、検証をスキップすると攻撃者がペイロードを改ざん可能


# data = jwt.decode(token, options={"verify_signature": False})

      • 安全な代替 (署名検証の必須化): 常に秘密鍵を用いた署名検証を必須とする。

        import jwt
from jwt.exceptions import InvalidTokenError

SECRET_KEY = "your-very-secret-key-that-should-be-long-and-random" # KMSから取得推奨

def decode_secure_jwt(token: str) -> dict:
    """
    JWTトークンを安全にデコードする関数。
    署名検証、有効期限チェック、アルゴリズム指定を厳密に行う。
    入力: token (str) - 検証するJWT文字列
    出力: dict - デコードされたペイロード、または例外
    前提: SECRET_KEYがサーバー側で安全に管理されている。
    計算量: O(N) - トークン長に比例（暗号処理）
    メモリ条件: トークン長に依存
    """
    try:

        # アルゴリズムを明示的に指定し、Noneアルゴリズムを拒否

        payload = jwt.decode(
            token,
            SECRET_KEY,
            algorithms=["HS256", "RS256"], # 許容するアルゴリズムを明示
            options={"require": ["exp", "iat"]} # 必須クレームを指定
        )
        return payload
    except InvalidTokenError as e:
        print(f"JWT検証失敗: {e}")
        raise # または適切なエラーハンドリング

  • セッション管理の強化:

    • 短命なセッション: セッションの有効期限を短く設定し、定期的に再認証を促します。

    • セッションの無効化: ログアウト、パスワード変更、非アクティブ状態によってセッションを速やかにサーバー側で無効化します。

    • 強力なセッションID: 推測が困難な高エントロピーなセッションIDを生成します。HttpOnly および Secure フラグをCookieに設定し、XSS攻撃によるセッションID窃取を防ぎます。

  • レート制限: ログインエンドポイントへのリクエスト数に制限を設け、ブルートフォース攻撃を防ぎます。

運用対策：鍵/秘匿情報の取り扱い、監査、最小権限

セキュリティは一度設定すれば終わりではありません。継続的な運用対策が不可欠です。

鍵/秘匿情報の取り扱い

APIキー、データベースの資格情報、暗号鍵などの秘匿情報は、常に安全に管理される必要があります。

  • 鍵管理システム (KMS) の活用: AWS KMS, Azure Key Vault, Google Cloud KMS などのクラウドプロバイダのKMSを利用し、暗号鍵の生成、保存、利用、ローテーションを一元的に管理します。アプリケーションコードに直接埋め込むことは絶対に避けます。

  • 環境変数/シークレット管理サービス: Kubernetes Secrets, HashiCorp Vault, AWS Secrets Manager などを使用し、実行時に安全に秘匿情報をアプリケーションに渡します。

    • 安全な環境変数利用例 (Bash):

      # 誤った例: スクリプト内にAPIキーを直接記述


# API_KEY="sk_**********" python your_script.py

# 安全な例: 環境変数として一時的に設定し、スクリプトから読み込む


# 鍵管理システムから安全に取得したキーを変数に格納

export API_KEY=$(aws secretsmanager get-secret-value --secret-id MyApiSecret --query SecretString --output text)
python your_script.py # スクリプトはos.environ['API_KEY']でキーを取得

# セキュリティを高めるため、必要なくなったキーはunsetする

unset API_KEY

  • 鍵のローテーション: 定期的に（例: 90日ごと）すべての暗号鍵やAPIキーをローテーションし、漏洩リスクを低減します。自動化されたローテーションを実装することが理想です。

最小権限の原則

ユーザー、サービスアカウント、APIキーには、その機能遂行に最低限必要な権限のみを付与します。

  • ロールベースアクセス制御 (RBAC): ユーザーやシステムを特定のロールに割り当て、そのロールに応じたアクセス権限を定義します。開発者や運用者であっても、本番環境への管理者権限は厳しく制限し、必要な場合にのみ一時的に付与します。

  • APIゲートウェイでのアクセス制御: APIゲートウェイで、特定のAPIエンドポイントへのアクセスを、クライアントIPアドレス、認証トークンの内容、カスタムヘッダーなどに基づいて制限します。

監査とロギング

すべてのAPIアクセス、認証試行、認可イベントを詳細に記録し、監査証跡を残します。

  • 詳細なアクセスログ: リクエスト元IPアドレス、ユーザーエージェント、タイムスタンプ、リクエストされたAPIエンドポイント、HTTPメソッド、リクエストパラメータの一部（機密情報を含まない範囲）、レスポンスコードを記録します。

  • セキュリティイベントログ: 認証成功/失敗、認可エラー、設定変更、鍵ローテーションなどのセキュリティ関連イベントを専用のログストリームに記録します。

  • 集中ログ管理とSIEM連携: ログデータをELK Stack (Elasticsearch, Logstash, Kibana) や Splunk などの集中ログ管理システムに集約し、SIEMと連携させることで、リアルタイム監視、相関分析、異常検出を可能にします。

現場の落とし穴

セキュリティ対策には、実運用で発生しうる課題が伴います。

  • 誤検知 (False Positives): WAFやAPIゲートウェイのセキュリティルールが厳しすぎると、正当なリクエストをブロックし、サービスの可用性を損なうことがあります。適切なチューニングとモニタリングが不可欠です。

  • 検出遅延: リアルタイムの脅威に対して、ログ分析やSIEMのアラートが遅れることがあります。重要なイベントについては、即座に担当者に通知されるような仕組みを構築する必要があります。

  • 可用性とのトレードオフ: 厳格なレート制限やIP制限はセキュリティを向上させますが、正当なトラフィックや急な負荷増大に対応できず、サービスの可用性を低下させる可能性があります。ビジネス要件とセキュリティ要件のバランスを見極める必要があります。

  • シャドウAPI (Shadow APIs): 適切なインベントリ管理（API09:2023 Improper Inventory Management）を怠ると、文書化されていない、あるいは開発者が知らないAPIエンドポイントが本番環境に残存し、それが新たな攻撃経路となることがあります。定期的なAPIディスカバリーと棚卸しを実施することが重要です。

まとめ

OWASP API Security Top 10 (2023)は、APIのセキュリティリスクに対する包括的な指針を提供します。BOLAやBroken Authenticationをはじめとする脅威に対しては、厳格な認可チェック、多要素認証、強力なセッション管理、そして鍵管理システムによる秘匿情報の安全な運用が不可欠です。

実務においては、これらの技術的対策に加えて、開発ライフサイクル全体でのセキュリティ組み込み（Security by Design）、継続的な監視、そして定期的な監査が求められます。誤検知や可用性とのトレードオフといった現場の課題を認識し、ビジネス要件とセキュリティリスクのバランスを取りながら、継続的にセキュリティ態勢を強化していくことが、実務家のセキュリティエンジニアに課せられた重要な責務です。

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

コメント

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