V13: API と Web サービス

管理目標

信頼できるサービスレイヤ API (一般的には JSON や XML や GraphQL を使用) を使用する検証対象のアプリケーションが以下を備えていることを確認します。

  • すべての Web サービスの適切な認証、セッション管理、認可。

  • 下位から上位の信頼レベルに遷移するすべてのパラメータの入力妥当性検査。

  • クラウドおよびサーバレス API を含むすべての API タイプに対する効果的なセキュリティ管理策。

この章を他のすべての章と同じレベルで組み合わせて読んでください。認証や API セッション管理の問題が重複することはなくなりました。

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

#
説明
L1
L2
L3
CWE

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 スキーマバリデーションライブラリを注意深く監視します。

#
説明
L1
L2
L3
CWE

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 サービス

#
説明
L1
L2
L3
CWE

13.3.1

適切に形成された XML 文書を確保するために XSD スキーマバリデーションが行われ、次にそのデータの処理が行われる前に各入力フィールドのバリデーションが行われる。

20

13.3.2

クライアントとサービス間の信頼できるトランスポートを確保するために、メッセージペイロードが WS-Security を使用して署名されている。

345

注意: DTD に対する XXE 攻撃の問題があるため、DTD バリデーションは使用すべきではありません。また、V14 構成で説明されている要件に従い、フレームワーク DTD 評価を無効にします。

V13.4 GraphQL

#
説明
L1
L2
L3
CWE

13.4.1

高く、ネストされたクエリの結果として GraphQL またはデータレイヤ式のサービス拒否 (Denial of Service, DoS) を防止するために、クエリ許可リスト、または深さ制限と量制限の組み合わせが使用されている。より高度なシナリオでは、クエリコスト分析を使用すべきである。

770

13.4.2

GraphQL および他のデータ層認証ロジックは GraphQL 層ではなくビジネスロジック層に実装されるべきである。

285

参考情報

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

Last updated

Was this helpful?