Skip to content

Latest commit

 

History

History
94 lines (68 loc) · 10.1 KB

0x21-V13-API.md

File metadata and controls

94 lines (68 loc) · 10.1 KB

V13 API と Web サービス

管理目標

Web ブラウザや他のコンシューマが使用する API を公開するアプリケーション (通常 JSON, XML, GraphQL を使用) が、関連するセキュリティ構成とメカニズムを適用していることを確認します。

この章は他のすべての章の同じレベルと組み合わせて読んでください。認証、セッション管理、一般的な入力バリデーションの問題とは重複していません。それよりも、これらの章の一般的な要件は常に適用されるので、この章をコンテキストから外して個別にテストすることはできません。

V1.13 API と Web サービスのドキュメント

これは将来のドキュメント要件のためのプレースホルダです。

V13.1 一般的な Web サービスセキュリティ

# 説明 L1 L2 L3 CWE
13.1.1 [5.5.5 へ移動]
13.1.2 [削除]
13.1.3 [削除, 8.3.1 へマージ]
13.1.4 [削除, 4.1.6 でカバー]
13.1.5 [削除, 不十分な影響]
13.1.6 [修正, 13.2.6 から移動, 13.3.2 をカバー, レベル L2 > L3] メッセージごとのデジタル署名を使用して、機密性が高いリクエストやトランザクションや、多数のシステムを横断するリクエストまたはトランザクションに対して、トランスポート保護の上にさらなる保証を提供している。 ✓ 345
13.1.7 [修正, 14.4.1 から移動, 5.3.2 をカバー] メッセージボディを持つすべての HTTP レスポンスにはレスポンスの実際のコンテンツと一致する Content-Type ヘッダフィールドを含んでいる。これには "text/", "/+xml", "/xml" などの IANA メディアタイプに従って安全な文字エンコーディング (UTF-8, ISO-8859-1 など) を指定する charset パラメータを含んでいる。 ✓ ✓ ✓ 173
13.1.8 [追加] ユーザ向けのエンドポイント (手動でのウェブブラウザアクセス用) のみが HTTP から HTTPS に自動的にリダイレクトし、他のサービスやエンドポイントでは透過的なリダイレクトを実装していない。これは、クライアントが誤って暗号化されていない HTTP リクエストを送信しても、リクエストが自動的に HTTPS に自動的にリダイレクトされるため機密データの漏洩が発見されない、という状況を避けるためである。 ✓ ✓

V13.2 Web サービス

現時点では、JSON スキーマバリデーション仕様の「公開バージョン」があり、運用準備が整っていると考えられています。しかしながら、厳密には「安定版」とみなされるバージョンはまだありません。そのため、JSON スキーマバリデーションの使用を検討する場合は、ASVS の第 5 章の標準入力バリデーションガイダンスも必ず適用してください。

JSON スキーマバリデーション仕様の正式な安定バージョンが存在しないため、使用している JSON スキーマバリデーションライブラリを注意深く監視してください。標準が正式化され、リファレンス実装のバグを解決すると、更新が必要になる可能性があるためです。

注：DTD に対する XXE 攻撃の問題があるため、DTD 検証は使用しないでください。また、V5 章で設定された要件に従って、フレームワーク DTD 評価を無効にしてください。

# 説明 L1 L2 L3 CWE
13.2.1 [13.6.2 へ移動]
13.2.2 [修正, 13.3.1 からマージ, レベル L1 > L3] 構造化データオブジェクトは、適切に形成されていることを確認するために検証され、その後、そのデータの処理が行われる前に各入力フィールドのバリデーションが行われている。これには、JSON や XML などの形式のスキーマバリデーションを実装することを含むことがある。 ✓ 20
13.2.3 [削除, 50.4.1 へマージ]
13.2.4 [削除]
13.2.5 受信した Content-Type が application/xml や application/json などの予期されるものであることを、REST サービスが明示的に検査している。 ✓ ✓ 436
13.2.6 [13.1.6 へ移動]

V13.3 SOAP Web サービス

# 説明 L1 L2 L3 CWE
13.3.1 [削除, 13.2.2 へマージ]
13.3.2 [削除, 13.1.6 でカバー]

V13.4 GraphQL

GraphQL はさまざまなバックエンドサービスと連携しないデータリッチなクライアントを作成する方法として、より一般的になりつつあります。しかし、このメカニズムにはセキュリティに関する特別な考慮事項もいくつかあります。

# 説明 L1 L2 L3 CWE
13.4.1 [文法] 高コストで、ネストされたクエリの結果として GraphQL またはデータレイヤエクスプレッションがサービス運用妨害（DoS）となることを防止するために、クエリ許可リストまたは、Depth 制限と量の制限の組み合わせを使用している。より高度なシナリオでは、クエリコスト分析を使用する必要があります。 ✓ ✓ 770
13.4.2 [修正] 認可ロジックが、GraphQL レイヤやリゾルバレイヤではなくビジネスロジックレイヤに実装されている。 ✓ ✓ 285
13.4.3 [追加] Graph API が他の関係者により使用されることを意図している場合を除き、本番環境では GraphQL イントロスペクションクエリが無効になっている。 ✓ ✓

V13.5 WebSocket

# 説明 L1 L2 L3 CWE
13.5.1 [追加] WebSocket over TLS (WSS) がすべての WebSocket 接続に使用されている。 ✓ ✓ ✓ 319
13.5.2 [追加] 最初の HTTP WebSocket ハンドシェイクで Origin ヘッダフィールドがアプリケーションで許可されているオリジンのリストと照合されている。 ✓ ✓ ✓ 346
13.5.3 [追加] アプリケーションの標準セッション管理を使用できない場合、関連するセッション管理セキュリティ要件に準拠した専用トークンが使用されている。 ✓ ✓ ✓ 331
13.5.4 [追加] 専用の WebSocket セッション管理トークンは、既存の HTTPS セッションを WebSocket チャネルに移行するときに、以前に認証された HTTPS セッションを通じて最初に取得または検証されます。 ✓ ✓ ✓ 319

V13.6 HTTP リクエストヘッダのバリデーション

# 説明 L1 L2 L3 CWE
13.6.1 [修正, 14.5.1 から移動] アプリケーションはアプリケーションまたは API が使用している HTTP メソッド (preflight リクエスト時の OPTIONS を含む) にのみ応答し、未使用のメソッド (TRACE など) はブロックされる。 ✓ ✓ ✓ 749
13.6.2 [修正, 13.2.1 から移動] HEAD、OPTIONS、TRACE、または GET verb を使用する HTTP リクエストがバックエンドデータ構造を変更することや、状態変更アクションを実行することがない。これらのリクエストは安全なメソッドであり、副作用があってはいけない。 ✓ ✓ ✓ 650
13.6.3 [追加] ロードバランサ、ファイアウォール、アプリケーションサーバを含むすべてのアプリケーションコンポーネントは RFC 2616 に準拠しており、Transfer-Encoding ヘッダフィールドが存在する場合には Content-Length ヘッダフィールドを無視して、HTTP リクエストスマグリングを防いでいる。 ✓ ✓ 444
13.6.4 [追加] アプリケーションにより使用され、ロードバランサやプロキシなどの中間デバイスにより定義された、X-Real-IP や X-Forwarded-* のような HTTP ヘッダフィールドがエンドユーザによってオーバーライドできない。 ✓ ✓ 346

V13.7 HTTP/2

# 説明 L1 L2 L3 CWE
13.7.1 [追加] Content-Length リクエストヘッダフィールドの値がビルトインのメカニズムを使用して計算された長さと一致している。 ✓ ✓ ✓ 400
13.7.2 [追加] すべての Transfer-Encoding ヘッダフィールドがメッセージから削除されるか、リクエストが完全にブロックされている。 ✓ ✓ ✓
13.7.3 [追加] フル CRLF (\r\n) シーケンスは HTTP/2 ヘッダ内で無効化されている。 ✓ ✓ ✓ 113

参考情報

詳しくは以下の情報を参照してください。