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