V2: バリデーションとビジネスロジック
管理目標
検証対象のアプリケーションが以下の上位要件を満たすことを確認します。
アプリケーションが受け取る入力はビジネスまたは機能上の期待と一致している。
ビジネスロジックフローは正しい手順通りに処理され、省略できない。
ビジネスロジックに自動攻撃を検知し防止する制限とコントロールを含んでいる。自動攻撃の例としては、連続的な少額の送金や一度に百万人の友人の追加がある。
高い価値を持つビジネスロジックフローにおいて悪用ケースや悪用する人を想定している。また、なりすまし、改竄、情報漏洩、権限昇格攻撃の対策を行っている。
V2.1 バリデーションとビジネスドキュメント
バリデーションとビジネスロジックドキュメントは、ビジネスロジックの制限、バリデーションルール、および組み合わされたデータ項目のコンテキストの一貫性を明確に定義して、アプリケーションに実装する必要があるものを明確にする必要があります。
2.1.1
アプリケーションのドキュメントには、期待される構造に対するデータ項目の妥当性をチェックする方法についての入力バリデーションルールを定義している。これは、クレジットカード番号、電子メールアドレス、電話番号のような一般的なデータ形式のこともあれば、内部データ形式のこともある。
1
v5.0.be-1.11.5
2.1.2
アプリケーションのドキュメントには、地区と郵便番号が一致することをチェックするなど、組み合わされたデータ項目の論理的およびコンテキスト的な一貫性を検証する方法を定義している。
2
v5.0.be-1.11.6
2.1.3
ビジネスロジックの制限とバリデーションに対する期待は、ユーザーごと、およびアプリケーション全体にわたって文書化されている。
2
v5.0.be-1.11.4
V2.2 入力バリデーション
効果的な入力バリデーションコントロールは、アプリが受け取ることを期待するデータの種類に関して、ビジネスまたは機能上の期待を強制します。これにより優れたデータ品質を確保して攻撃対象領域を減らします。但し、他のコンポーネントでデータを使用する場合や出力にデータを提示する場合、正しいエンコーディング、パラメータ化、サニタイゼーションを使用する必要性をなくしたり置き換わるわけではありません。
このコンテキストでは、「入力」は、HTML フォームフィールド、REST リクエスト、URL パラメータ、HTTP ヘッダフィールド、クッキー、ディスク上のファイル、データベース、外部 API など、さまざまなソースからもたらされる可能性があります。
ビジネスロジックコントロールでは特定の入力を 100 未満の数値であるかどうかをチェックするかもしれません。機能上の期待としては、数値が特定の閾値未満であるかどうかをチェックすることがあります。その数値は特定のループを実行する回数を制御しており、高い数値は過剰な処理と潜在的なサービス拒否状態につながる可能性があるためです。
スキーマバリデーションを明示的に義務付けてはいませんが、JSON や XML を使用する HTTP API やその他のインタフェースの完全なバリデーションをカバーするには、これが最も効果的なメカニズムかもしれません。
スキーマバリデーションについては以下の点に注意してください。
JSON スキーマバリデーション仕様の「公開バージョン」は運用準備が整っていると考えられていますが、厳密には「安定版」ではありません。JSON スキーマバリデーションを使用する場合は、以下の要件のガイダンスとのギャップがないことを確認してください。
使用している JSON スキーマバリデーションライブラリも監視して、標準が正式に制定されたら、必要に応じて更新する必要があります。
DTD に対する XXE 攻撃の問題を回避するため、DTD バリデーションは使用すべきではありません。また、フレームワークの DTD 評価を無効にする必要があります。
2.2.1
入力はその入力に対するビジネスまたは機能上の期待を満たすことを検証されている。これは、許容される値、パターン、範囲のリストに対する肯定的なバリデーションを使用するか、あらかじめ定義されたルールに従って、期待される構造および論理的限界と入力との比較に基づく必要がある。L1 では、これは特定のビジネスまたはセキュリティ上の意思決定に使用される入力に焦点を当てることができる。L2 以上では、これはすべての入力に適用する必要がある。
1
v5.0.be-11.3.1
2.2.2
アプリケーションは信頼できるサービスレイヤで入力バリデーションを実行するように設計されている。クライアントサイドのバリエーションはユーザービリティを向上するため推奨されるが、セキュリティコントロールとしては依存してはいけない。
1
v5.0.be-11.3.2
2.2.3
アプリケーションは、関連するデータ項目の組み合わせが事前に定義されたルールに従って妥当であることを確保している。
2
v5.0.be-11.3.3
V2.3 ビジネスロジックのセキュリティ
このセクションでは、アプリケーションがビジネスロジックプロセスを正しい方法で実行し、アプリケーションのロジックとフローを悪用する攻撃に対して脆弱にならないようにするための主要な要件について検討します。
2.3.1
アプリケーションは同じユーザのビジネスロジックフローを期待した正しい手順通り、省略せずに処理する。
1
v5.0.be-11.1.1
2.3.2
ビジネスロジックの制限はアプリケーションのドキュメントに従って実装され、ビジネスロジックの欠陥が悪用されることを避けている。
2
v5.0.be-11.1.3
2.3.3
トランザクションはビジネスロジックレベルで使用されてビジネスロジックオペレーション全体が成功するか、以前の正しい状態にロールバックされる。
2
v5.0.be-11.1.9
2.3.4
価値の高いロジックフローは複数ユーザの承認を必要とし、不正なアクションや偶発的なアクションを防いでいる。これには、多額の送金、契約の承認、機密情報へのアクセス、製造における安全のオーバーライドなどが含まれるが、これらに限定されない。
3
v5.0.be-11.1.10
V2.4 アンチオートメーション
このセクションは、人間のようなインタラクションが要求され、過剰な自動化リクエストが防止されるようにするためのアンチオートメーションコントロールを含みます。
2.4.1
アンチオートメーションコントロールが導入され、データ流出、ガベージデータ作成、クォータ枯渇、レート制限違反、サービス拒否、高価なリソースの過剰使用につながる可能性のあるアプリケーション機能への過剰な呼び出しから保護している。
2
v5.0.be-11.2.2
2.4.2
ビジネスロジックフローは現実的な人間のタイミングを必要とし、過度に迅速なトランザクション送信を防いでいる。
3
v5.0.be-11.2.1
参考情報
詳しくは以下の情報を参照してください。
Last updated
Was this helpful?