V13: API と Web サービス
管理目標
信頼できるサービスレイヤ API (一般的には JSON や XML や GraphQL を使用) を使用する検証対象のアプリケーションが以下を備えていることを確認します。
すべての Web サービスの適切な認証、セッション管理、認可。
下位から上位の信頼レベルに遷移するすべてのパラメータの入力妥当性検査。
クラウドおよびサーバレス API を含むすべての API タイプに対する効果的なセキュリティ管理策。
この章を他のすべての章と同じレベルで組み合わせて読んでください。認証や API セッション管理の問題が重複することはなくなりました。
V13.1 一般的な Web サービスセキュリティ検証
13.1.1
SSRF および RFI 攻撃で使用される可能性のあるさまざまな URI やファイルパース動作を悪用するパース攻撃を回避するために、すべてのアプリケーションコンポーネントが同じエンコードおよびパーサーを使用する。
✓
✓
✓
116
13.1.2
[削除, 4.3.1 と重複]
13.1.3
API URL は API キー、セッショントークンなどの機密情報を公開していない。
✓
✓
✓
598
13.1.4
認証判定は URI (コントローラーまたはルーターのプログラム型または宣言型のセキュリティにより実施される) とリソースレベル (モデルベースの許可により実施される) の両方で行われている。
✓
✓
285
13.1.5
予期しないまたは欠落しているコンテンツタイプを含むリクエストは適切なヘッダ (HTTP レスポンスステータス 406 Unacceptable または 415 Unsupported Media Type) で拒否される。
✓
✓
434
V13.2 RESTful Web サービス検証
JSON スキーマバリデーションは標準化のドラフト段階にあります (参考情報を参照) 。RESTful Web サービスのベストプラクティスである JSON スキーマバリデーションの使用を検討する際には、JSON スキーマバリデーションと組み合わせて以下の付加的なデータバリデーション戦略を使用することを検討します。
欠落した要素や余計な要素があるかどうかなど、JSON オブジェクトのパースバリデーション。
データ型、データ形式、長さなどの標準入力バリデーション手法を用いた JSON オブジェクト値のバリデーション。
正式な JSON スキーマバリデーション。
JSON スキーマバリデーション標準が正式化されれば、ASVS はこの領域のアドバイスを更新します。標準が正式化されてバグが参照実装から取り除かれるまで定期的に更新される必要があるため、使用中の JSON スキーマバリデーションライブラリを注意深く監視します。
13.2.1
保護された API またはリソースに対して DELETE または PUT を使用することを防ぐなど、使用可能な RESTful HTTP メソッドがユーザまたはアクションにとって有効な選択である。
✓
✓
✓
650
13.2.2
JSON スキーマバリデーションが設定されており入力を受け付ける前に検証されている。
✓
✓
✓
20
13.2.3
クッキーを利用する RESTful ウェブサービスは、ダブル送信クッキーパターン、CSRF ノンス、Origin リクエストヘッダチェックのうち少なくとも一つ以上を使用して、クロスサイトリクエストフォージェリから保護されている。
✓
✓
✓
352
13.2.4
[削除, 11.1.4 と重複]
13.2.5
REST サービスは受信する Content-Type を application/xml や application/json などの予期されたものであることを明示的に確認する。
✓
✓
436
13.2.6
メッセージヘッダとペイロードが信頼でき、転送中に改変されていない。トランスポートに強力な暗号化 (TLS のみ) を要求することは機密性と完全性の両方の保護を提供するため、多くの場合には十分かもしれない。メッセージごとのデジタル署名は、高度なセキュリティを必要とするアプリケーションに対してトランスポート保護に加えてさらなる保証を提供できるが、その利点に反して複雑さとリスクの増加をもたらす。
✓
✓
345
V13.3 SOAP Web サービス
13.3.1
適切に形成された XML 文書を確保するために XSD スキーマバリデーションが行われ、次にそのデータの処理が行われる前に各入力フィールドのバリデーションが行われる。
✓
✓
✓
20
13.3.2
クライアントとサービス間の信頼できるトランスポートを確保するために、メッセージペイロードが WS-Security を使用して署名されている。
✓
✓
345
注意: DTD に対する XXE 攻撃の問題があるため、DTD バリデーションは使用すべきではありません。また、V14 構成で説明されている要件に従い、フレームワーク DTD 評価を無効にします。
V13.4 GraphQL
13.4.1
高く、ネストされたクエリの結果として GraphQL またはデータレイヤ式のサービス拒否 (Denial of Service, DoS) を防止するために、クエリ許可リスト、または深さ制限と量制限の組み合わせが使用されている。より高度なシナリオでは、クエリコスト分析を使用すべきである。
✓
✓
770
13.4.2
GraphQL および他のデータ層認証ロジックは GraphQL 層ではなくビジネスロジック層に実装されるべきである。
✓
✓
285
参考情報
詳しくは以下の情報を参照してください。
Last updated
Was this helpful?