V13: API と Web サービス
管理目標
Web ブラウザや他のコンシューマが使用する API を公開するアプリケーション (通常 JSON, XML, GraphQL を使用) には、特にいくつかの考慮事項が適用されます。この章では、関連するセキュリティ構成と適用すべきメカニズムについて説明します。
この章は他のすべての章の同じレベルと組み合わせて読んでください。認証、セッション管理、一般的な入力バリデーションの問題とは重複していません。それよりも、これらの章の一般的な要件は常に適用されるので、この章をコンテキストから外して個別にテストすることはできません。
V13.1 一般的な Web サービスセキュリティ
このセクションでは、一般的な Web サービスセキュリティの考慮事項と、その結果としての基本的な Web サービス衛生習慣全般について説明します。
13.1.7
[修正, 14.4.1 から移動, 5.3.2 をカバー] メッセージボディを持つすべての HTTP レスポンスにはレスポンスの実際のコンテンツと一致する Content-Type ヘッダフィールドを含んでいる。これには "text/", "/+xml", "/xml" などの IANA メディアタイプに従って安全な文字エンコーディング (UTF-8, ISO-8859-1 など) を指定する charset パラメータを含んでいる。
1
v5.0.be-13.1.7
13.1.8
[追加] ユーザ向けのエンドポイント (手動でのウェブブラウザアクセス用) のみが HTTP から HTTPS に自動的にリダイレクトし、他のサービスやエンドポイントでは透過的なリダイレクトを実装していない。これは、クライアントが誤って暗号化されていない HTTP リクエストを送信しても、リクエストが自動的に HTTPS に自動的にリダイレクトされるため機密データの漏洩が発見されない、という状況を避けるためである。
2
v5.0.be-13.1.8
13.1.6
[修正, 13.2.6 から移動, 13.3.2 をカバー, レベル L2 > L3] メッセージごとのデジタル署名を使用して、機密性が高いリクエストやトランザクションや、多数のシステムを横断するリクエストまたはトランザクションに対して、トランスポート保護の上にさらなる保証を提供している。
3
v5.0.be-13.1.6
V13.6 HTTP リクエストヘッダバリデーション
このセクションでは、HTTP リクエストスマグリングやソーススプーフィングなどの攻撃を防ぐことができる HTTP リクエストヘッダバリデーションについて詳しく説明します。
13.6.2
[追加] ロードバランサ、ファイアウォール、アプリケーションサーバを含むすべてのアプリケーションコンポーネントは RFC 2616 に準拠しており、Transfer-Encoding ヘッダフィールドが存在する場合には Content-Length ヘッダフィールドを無視して、HTTP リクエストスマグリングを防いでいる。
2
v5.0.be-13.6.2
13.6.3
[追加] アプリケーションにより使用され、ロードバランサやプロキシなどの中間デバイスにより定義された、X-Real-IP や X-Forwarded-* のような HTTP ヘッダフィールドがエンドユーザによってオーバーライドできない。
2
v5.0.be-13.6.3
13.6.1
[追加, 14.5.1 から分割] アプリケーションまたはその API によって明示的にサポートされている HTTP メソッド (preflight リクエスト時の OPTIONS を含む) のみが使用でき、未使用のメソッドはブロックされる。
3
v5.0.be-13.6.1
V13.7 HTTP/2
このセクションでは、HTTP/2 に関連する特定のセキュリティ上の考慮事項に焦点を当てます。以下の要件は HTTP/3 にも適用される可能性があることに注意してください。
13.7.1
[追加] HTTP/2 から古い HTTP バージョンにダウングレードする場合、リクエストの長さを計算するための標準メカニズムが使用される。リクエストスマグリング脆弱性につながる可能性があるため、競合する Content-Length ヘッダフィールドと Transfer-Encoding ヘッダフィールドが導入されないようにする。
3
v5.0.be-13.7.1
13.7.2
[追加] レスポンス分割やヘッダインジェクション攻撃を防ぐために、すべての Transfer-Encoding ヘッダフィールドが HTTP/2 メッセージから取り除かれるか、それらを含む HTTP/2 リクエストが拒否される。
3
v5.0.be-13.7.2
13.7.3
[追加] ヘッダインジェクション攻撃を防ぐために、HTTP/2 ヘッダフィールド内のフル CRLF (\r\n) シーケンスが削除されるか拒否される。
3
v5.0.be-13.7.3
V13.4 GraphQL
GraphQL はさまざまなバックエンドサービスと連携しないデータリッチなクライアントを作成する方法として、より一般的になりつつあります。このセクションでは GraphQL のセキュリティに関する考慮事項について説明します。
13.4.1
[文法] コストが高く、ネストされたクエリの結果としての GraphQL やデータレイヤエクスプレッションのサービス拒否 (DoS) を防止するために、クエリ許可リスト、深さ制限、量制限、またはクエリコスト分析を使用している。
2
v5.0.be-13.4.1
13.4.3
[追加] Graph API が他の関係者により使用されることを意図している場合を除き、本番環境では GraphQL イントロスペクションクエリが無効になっている。
2
v5.0.be-13.4.3
V13.5 WebSocket
WebSocket は単一の TCP 接続で同時双方向通信チャネルを提供する通信プロトコルです。2011 年に IETF によって RFC 6455 として標準化され、HTTP ポート 443 と 80 で動作するように設計されていますが、HTTP とは異なります。
このセクションでは、特にこのリアルタイム通信チャネルを悪用する、通信セキュリティとセッション管理に関連する攻撃を防ぐための主要なセキュリティ要件について説明します。
13.5.1
[追加] WebSocket over TLS (WSS) がすべての WebSocket 接続に使用されている。
1
v5.0.be-13.5.1
13.5.2
[追加] 最初の HTTP WebSocket ハンドシェイクで Origin ヘッダフィールドがアプリケーションで許可されているオリジンのリストと照合されている。
2
v5.0.be-13.5.2
13.5.3
[追加] アプリケーションの標準セッション管理を使用できない場合、関連するセッション管理セキュリティ要件に準拠した専用トークンが使用されている。
2
v5.0.be-13.5.3
13.5.4
[追加] 専用の WebSocket セッション管理トークンは、既存の HTTPS セッションを WebSocket チャネルに移行するときに、以前に認証された HTTPS セッションを通じて最初に取得または検証されます。
2
v5.0.be-13.5.4
参考情報
詳しくは以下の情報を参照してください。
graphql.org と Apollo の GraphQL Authorization のリソース
Last updated
Was this helpful?