V13: API および Web サービス
管理目標
Web ブラウザや他のコンシューマが使用する API を公開するアプリケーション (通常 JSON, XML, GraphQL を使用) が、関連するセキュリティ構成とメカニズムを適用していることを確認します。
この章は他のすべての章の同じレベルと組み合わせて読んでください。認証、セッション管理、一般的な入力バリデーションの問題とは重複していません。それよりも、これらの章の一般的な要件は常に適用されるので、この章をコンテキストから外して個別にテストすることはできません。
V13.1 一般的な Web サービスセキュリティ検証
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
13.1.1 | [5.5.5 へ移動] | ||||
13.1.2 | [削除, 4.3.1 と重複] | ||||
13.1.3 | [削除, 8.3.1 へマージ] | ||||
13.1.4 | [削除, 4.2.1 と重複]] | ||||
13.1.5 | [削除, 不十分な影響] | ||||
13.1.6 | [修正, 13.2.6 から移動, レベル L2 > L3] メッセージごとのデジタル署名を使用して、機密性が高いリクエストやトランザクションや、多数のシステムを横断するリクエストまたはトランザクションに対して、トランスポート保護の上にさらなる保証を提供している。 | ✓ | 345 |
V13.2 RESTful Web サービス検証
現時点では、JSON スキーマバリデーション仕様の「公開バージョン」があり、運用準備が整っていると考えられています。しかしながら、厳密には「安定版」とみなされるバージョンはまだありません。そのため、JSON スキーマバリデーションの使用を検討する場合は、ASVS の第 5 章の標準入力バリデーションガイダンスも必ず適用してください。
JSON スキーマバリデーション仕様の正式な安定バージョンが存在しないため、使用している JSON スキーマバリデーションライブラリを注意深く監視してください。標準が正式化され、リファレンス実装のバグを解決すると、更新が必要になる可能性があるためです。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
13.2.1 | [14.5.5 へ移動] | ||||
13.2.2 | [レベル L1 > L3] JSON スキーマバリデーションが設定されており入力を受け付ける前に検証されている。 | ✓ | 20 | ||
13.2.3 | [削除, 50.3.1 へマージ] | ||||
13.2.4 | [削除, 11.1.4 と重複] | ||||
13.2.5 | REST サービスは受信する Content-Type を application/xml や application/json などの予期されたものであることを明示的に確認する。 | ✓ | ✓ | 436 | |
13.2.6 | [13.1.6 へ移動] |
V13.3 SOAP Web サービス
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
13.3.1 | 適切に形成された XML 文書を確保するために XSD スキーマバリデーションが行われ、次にそのデータの処理が行われる前に各入力フィールドのバリデーションが行われる。 | ✓ | ✓ | ✓ | 20 |
13.3.2 | [削除, 13.2.6 と重複] |
注意: DTD に対する XXE 攻撃の問題があるため、DTD バリデーションは使用すべきではありません。また、V5 章で説明されている要件に従い、フレームワーク DTD 評価を無効にします。
V13.4 GraphQL
GraphQL はさまざまなバックエンドサービスと連携しないデータリッチなクライアントを作成する方法として、より一般的になりつつあります。しかし、このメカニズムにはセキュリティに関する特別な考慮事項もいくつかあります。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
13.4.1 | 高く、ネストされたクエリの結果として GraphQL またはデータレイヤ式のサービス拒否 (Denial of Service, DoS) を防止するために、クエリ許可リスト、または深さ制限と量制限の組み合わせが使用されている。より高度なシナリオでは、クエリコスト分析を使用すべきである。 | ✓ | ✓ | 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 |
参考情報
詳しくは以下の情報を参照してください。
graphql.org と Apollo の GraphQL Authorization のリソース
Last updated