> For the complete documentation index, see [llms.txt](https://coky-t.gitbook.io/owasp-asvs-ja/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://coky-t.gitbook.io/owasp-asvs-ja/owasp-apurikshonsekyuriti-50/0x13-v4-api-and-web-service.md). # V4: API と Web サービス ## 管理目標 Web ブラウザや他のコンシューマが使用する API を公開 (通常 JSON, XML, GraphQL を使用) するアプリケーションには、特にいくつかの考慮すべき事項があります。この章では、関連するセキュリティ構成と適用すべきメカニズムについて説明します。 他の章にある認証、セッション管理、入力バリデーションの懸念事項は API にも適用されるので、この章をコンテキストから切り離したり、個別にテストすることはできないことに注意してください。 ## V4.1 一般的な Web サービスセキュリティ このセクションでは、一般的な Web サービスセキュリティの考慮事項と、その結果としての基本的な Web サービス衛生習慣について説明します。 | # | 説明 | レベル | | :-------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :-: | | **4.1.1** | メッセージボディを持つすべての HTTP レスポンスにはレスポンスの実際のコンテンツと一致する Content-Type ヘッダフィールドを含んでいる。これには "text/", "/+xml", "/xml" などの IANA メディアタイプに従って安全な文字エンコーディング (UTF-8, ISO-8859-1 など) を指定する charset パラメータを含んでいる。 | 1 | | **4.1.2** | ユーザ向けのエンドポイント (手動でのウェブブラウザアクセス用) のみが HTTP から HTTPS に自動的にリダイレクトし、他のサービスやエンドポイントでは透過的なリダイレクトを実装していない。これは、クライアントが誤って暗号化されていない HTTP リクエストを送信しても、リクエストが自動的に HTTPS に自動的にリダイレクトされるため機密データの漏洩が発見されない、という状況を避けるためである。 | 2 | | **4.1.3** | アプリケーションにより使用され、ロードバランサ、Web プロキシ、backend-for-frontend サービスなどの中間層により設定される HTTP ヘッダフィールドはエンドユーザによって上書きできない。ヘッダの例としては X-Real-IP, X-Forwarded-\*, X-User-ID などがある。 | 2 | | **4.1.4** | アプリケーションまたはその API によって明示的にサポートされている HTTP メソッド (preflight リクエスト時の OPTIONS を含む) のみが使用でき、未使用のメソッドはブロックされる。 | 3 | | **4.1.5** | メッセージごとのデジタル署名を使用して、機密性が高いリクエストやトランザクションや、多数のシステムを横断するリクエストまたはトランザクションに対して、トランスポート保護の上にさらなる保証を提供している。 | 3 | ## V4.2 HTTP メッセージ構造バリデーション このセクションでは、リクエストスマグリング、レスポンス分割、ヘッダインジェクション、長すぎる HTTP メッセージによるサービス拒否などの攻撃を防ぐために、HTTP メッセージの構造とヘッダフィールドを検証する方法について説明します。 これらの要件は、一般的な HTTP メッセージの処理と生成に関連しますが、異なる HTTP バージョン間で HTTP メッセージを変換する際に特に重要です。 | # | 説明 | レベル | | :-------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-: | | **4.2.1** | すべてのアプリケーションコンポーネント (ロードバランサ、ファイアウォール、アプリケーションサーバを含む) は、HTTP バージョンに適したメカニズムを使用して、受信 HTTP メッセージの境界を決定し、HTTP リクエストスマグリングを防いでいる。HTTP/1.x では、Transfer-Encoding ヘッダフィールドが存在する場合、Content-Length ヘッダフィールドを RFC 2616 に従って無視する必要がある。HTTP/2 または HTTP/3 を使用する際に、Content-Length ヘッダフィールドが存在する場合、受信側はそれが DATA フレームの長さと一致することを確保する必要がある。 | 2 | | **4.2.2** | HTTP メッセージを生成する際、HTTP リクエストスマグリングを防ぐために、Content-Length ヘッダフィールドが HTTP プロトコルのフレームで決定されるコンテンツの長さと競合しない。 | 3 | | **4.2.3** | アプリケーションは、レスポンス分割やヘッダインジェクション攻撃を防ぐために、Transfer-Encoding などの接続固有のヘッダフィールドを持つ HTTP/2 や HTTP/3 メッセージを送受信しない。 | 3 | | **4.2.4** | アプリケーションは、ヘッダインジェクション攻撃を防ぐために、ヘッダフィールドと値に CR (\r)、LF (\n)、CRLF (\r\n) シーケンスを含まない HTTP/2 および HTTP/3 リクエストのみを受け付ける。 | 3 | | **4.2.5** | アプリケーション (バックエンドまたはフロントエンド) がリクエストを構築して送信する場合、バリデーション、サニタイゼーション、またはその他のメカニズムを使用して、受信コンポーネントで受け入れられるには長すぎる URI (API 呼び出しのためなど) や HTTP リクエストヘッダフィールド (認可やクッキーのためなど) の作成を回避している。長すぎるリクエスト (長いクッキーヘッダフィールドなど) を送信すると、サーバが常にエラーステータスで応答するなど、サービス拒否を引き起こす可能性がある。 | 3 | ## V4.3 GraphQL GraphQL はさまざまなバックエンドサービスと密結合しないデータリッチなクライアントを作成する方法として、より一般的になりつつあります。このセクションでは GraphQL のセキュリティに関する考慮事項について説明します。 | # | 説明 | レベル | | :-------: | ------------------------------------------------------------------------------------------------------------ | :-: | | **4.3.1** | コストが高く、ネストされたクエリの結果としての GraphQL やデータレイヤエクスプレッションのサービス拒否 (DoS) を防止するために、クエリ許可リスト、深さ制限、量制限、またはクエリコスト分析を使用している。 | 2 | | **4.3.2** | Graph API が他の関係者により使用されることを意図している場合を除き、本番環境では GraphQL イントロスペクションクエリが無効になっている。 | 2 | ## V4.4 WebSocket WebSocket は単一の TCP 接続で同時双方向通信チャネルを提供する通信プロトコルです。2011 年に IETF によって RFC 6455 として標準化され、HTTP ポート 443 と 80 で動作するように設計されていますが、HTTP とは異なります。 このセクションでは、特にこのリアルタイム通信チャネルを悪用する、通信セキュリティとセッション管理に関連する攻撃を防ぐための主要なセキュリティ要件について説明します。 | # | 説明 | レベル | | :-------: | ---------------------------------------------------------------------------------------------------------- | :-: | | **4.4.1** | WebSocket over TLS (WSS) がすべての WebSocket 接続に使用されている。 | 1 | | **4.4.2** | 最初の HTTP WebSocket ハンドシェイクで Origin ヘッダフィールドがアプリケーションで許可されているオリジンのリストと照合されている。 | 2 | | **4.4.3** | アプリケーションの標準セッション管理を使用できない場合、関連するセッション管理セキュリティ要件に準拠した専用トークンが使用されている。 | 2 | | **4.4.4** | 専用の WebSocket セッション管理トークンは、既存の HTTPS セッションを WebSocket チャネルに移行するときに、以前に認証された HTTPS セッションを通じて最初に取得または検証されます。 | 2 | ## 参考情報 詳しくは以下の情報を参照してください。 * [OWASP REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html) * [graphql.org](https://graphql.org/learn/authorization/) と [Apollo](https://www.apollographql.com/docs/apollo-server/security/authentication/#authorization-methods) の GraphQL Authorization のリソース * [OWASP Web Security Testing Guide: GraphQL Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL) * [OWASP Web Security Testing Guide: Testing WebSockets](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing/10-Testing_WebSockets)