この文書は2016年以降更新されていません

ビジネス ロジックのセキュリティに関するチートシート

OWASP 作成
ジャンプ先: 移動検索

ドラフト版チートシート - 編集中

はじめに

このチートシートでは、各種類のビジネス ロジックの脆弱性の一部の特定、被害の予防、およびテストのためのガイダンスを提供します。

ビジネス ロジックの脆弱性について

ビジネス ロジックに脆弱性があると、攻撃者は、ビジネス ルールを迂回してアプリケーションを不正使用できるようになります。セキュリティ問題の大半は、セキュリティ制御 (認証、アクセス制御、入力検証など) の破綻または欠落からもたらされる、アプリケーションの脆弱性によるものです。対照的に、ビジネス ロジックの脆弱性は、組織に被害を与えるような形でアプリケーションの正当な処理フローを使用する方法です。

ビジネス ロジックの問題について説明する記事の多くは、既存のよく知られた Web アプリケーション セキュリティの問題を取り上げて、脆弱性がもたらしたビジネス上の被害について説明しています。本当のビジネス ロジックの問題は、実際には典型的なセキュリティ脆弱性とは別物です。自動的にスキャンすることでは発見できないような脆弱性をとりあえずビジネス ロジックのカテゴリに分類しておくことがよくあります。そのために、明確な分類法の適用が非常に難しくなっています。おおまかな話をすれば、脆弱性を理解するために正しくビジネスを理解する必要があるとすれば、その時点ですでにビジネス ロジックの問題は発生しているのです。もしビジネスを理解していなかったら、脆弱性は、単なる典型的なアプリケーション脆弱性としてその他のカテゴリに分類されてしまいます。

たとえば、ある電子掲示板システムは、不適切用語リストと比較することで、初回の投稿に不適切な言葉が含まれないように設計されています。リストに含まれる単語が見つかると、投稿内容は掲載されません。ただし、一旦投稿が掲載されると、投稿者は掲載内容にアクセスして編集、変更し、不適切用語リストに登録されている言葉を含めることができます。これは、編集時には投稿内容がまったく検証されないためです。

ビジネス ルールの脆弱性のテストでは、ビジネス ルールで違反をしているのに、ビジネス プロセスが正常に完了するような、ビジネス ロジックの不正な使用例を作成します。

1. ビジネス ルールの特定とテスト事例/不正使用事例の導出

最初の手順は、注目すべきビジネス ルールを特定することです。そして、これをアプリケーションが適切にビジネス ルールを強制するかどうかを検証するための実験に変換します。 たとえば、1,000 ドルを超えた購入には 10% の割引きを適用するというルールの場合、ポジティブ テストとネガティブ テストは、次のように設計する必要があります。

  1. ) 制御はビジネス ルールを適切に実装している
  2. ) 制御は正しく実装されており、迂回や改ざんは不可能
  3. ) 制御は、すべての必要な場所で適切に使用されている

ビジネス ルールの脆弱性には、ビジネス プロセスを適切に完了するために整備されているビジネス ルール、制約、制限を迂回する形で、攻撃者がアプリケーションを不正使用することを許してしまう、あらゆる種類の脆弱性が含まれます。 たとえば、株式取引アプリケーションでは、攻撃者は 1 日の取引開始時間に取引を開始し、価格を固定し、その日の取引が終了するまで取引をオープンしたままにして、株価が上がった場合には売り、株価が下がった場合にはキャンセルします。 ビジネス ロジックのテストでは、機能テストの担当者が使用するものと同じテスト ツールとテスト技法を多数使用します。ビジネス ロジックのテストの大部分は、未だにテスト担当者の個人的スキル、ビジネス プロセスの完全な知識、ビジネス プロセスのルールに依存していますが、実際のテストでは機能/セキュリティのテスト ツールが使用されることもあります。

2. 時間関連のビジネス ルールについての考慮事項

TBD:アプリケーションが確定済みの注文の変更に使用される可能性がありますか (トランザクションを間違った順序で出現させるなど)。

アプリケーションは時間を認識する必要があり、攻撃者がトランザクションを開いたままにして、トランザクションの完了を妨害するのを許してはいけません (その方が好都合でない限り)。

3. 金銭関連のビジネス ルールについての考慮事項

TBD:ここでは、金銭的制限事項とその他の不適切なトランザクションをカバーしなければなりません。アプリケーションは、不適切な金融トランザクションを発生させるために使用できますか。NaN や無限大の使用を許可していますか。金銭のモデル化に使用されるデータ構造が原因で、不正確さが持ち込まれることがありますか。

4. プロセス関連のビジネス ルールについての考慮事項

TBD: これは、プロセス、承認、通信などにおける手順に向けたものです。アプリケーションは、プロセスにおける手順を迂回または悪用するために使用できますか。

ワークフローの脆弱性には、攻撃者が設計されたワークフローを回避したり、中断されたワークフローを継続する形でアプリケーションを不正使用することを許す、あらゆる種類の脆弱性が含まれます。たとえば、1 ドルごとに購入ポイントが付与される電子商取引サイトでは、取引が決済されるまで顧客のアカウントにポイントを適用しないようにします。決済前にアカウントにポイントを適用してしまうと、顧客が取引をキャンセルしても、誤ってポイントが付与されてしまいます。

アプリケーションでは、ユーザーが必ず正しい順序でプロセスの各手順を完了することを確認するチェック機能を備え、攻撃者がワークフローの手順/プロセスを迂回できないようにする必要があります。 ワークフロー脆弱性のテストには、プロセス内のステップを不適切な順序で実行することが含まれます。

5. 人事資源関連のビジネス ロジックについての考慮事項

TBD: これは、人事にまつわるルールのためのものです。アプリケーションは、人事手続きや標準に違反する形で使用できますか

6. 契約関係のビジネス ルールについての考慮事項

TBD: アプリケーションは、契約関係 (サービス プロバイダーとの契約など) に矛盾する方法で使用できますか

7. TBD - その他の実際のビジネス ルールについて考える

関連資料

警告: 次に示す記事に掲載されているほとんどの例は、実際にはビジネス ロジックの欠陥ではありません

  • 『Seven Business Logic Flaws That Put Your Website At Risk』、Jeremiah Grossman Founder および CTO、WhiteHat Security

https://www.whitehatsec.com/assets/WP_bizlogic092407.pdf

Authors and Primary Editors

Ashish Rao rao.ashish20[at]gmail.com
David Fern dfern[at]verizon.net

Other Cheatsheets

OWASP Cheat Sheets Project Homepage

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets