ビジネスロジックの欠陥

ビジネスロジックの欠陥とは？

ビジネスロジックの欠陥とは、アプリの実際の処理の流れを利用して、結果として組織に不利な影響を及ぼす手法のことです。

それでは、具体例を見てみましょう。

ある人物がXYZ.comというサイトで世界中に衣服を販売しています。以下のようなチェックアウトの手順が見受けられます。

1. 利用者は商品を少なくとも1点選び、カートに追加する
2. 利用者は購入手続きを始めるため、注文ページに進む
3. 利用者は支払い方法またはチェックアウトを選択する
4. 販売者は注文と利用者情報を決済サービスへ送信して認証を受ける
5. 決済サービスは取引IDを販売者であるXYZ.comへ返す
6. 販売者は利用者のページに確認情報を表示する

上記の流れでは、例えば第三段階で攻撃者が注文後の金額を操作し、『ルピー』から『米ドル』に変更できるため、販売者XYZ.comに対して金銭的な攻撃を仕掛けることが可能となります。結果として、攻撃者はこの欠陥を利用して注文時の支払い額を減らすことができました。

通常の使用では発見されにくいため、意識的に探さなければ気づかれにくい欠陥ですが、攻撃者は開発者が想定しない方法でアプリにアクセスすることで、これを悪用する可能性があります。

ビジネスロジックの基本的な目的は、アプリやサービスの設計時に定められたルールや制限を実装することにあります。つまり、特定の状況が発生した際にアプリがどのように反応すべきかを定め、利用者がビジネスに悪影響を及ぼす行動を取らないようにしています。

しかし、ロジックの欠陥は攻撃者にこれらのルールを回避させる可能性があります。たとえば、決められた購入プロセスを経ずに取引を完了させたり、利用者が入力した情報の検証が不十分なために、重要な属性を自由に変更できたりして、不正な取引が実行される恐れがあります。

また、ロジックの欠陥は非常に多様で、アプリやサービスごとに異なる場合があります。それらの特定には、攻撃者の意図を見抜くためのビジネス知識が必要となるため、機械的な脆弱性診断では検出が難しいのです。その結果、ロジックの欠陥はバグトラッカーや手動検査の重要な対象となります。

‍

ビジネスロジックの欠陥の影響とは？

ビジネスロジックの欠陥の影響は、場合によっては小さいこともあります。一般的なカテゴリであり、影響度は事例によって大きく異なります。しかし、攻撃者が巧妙にアプリを操作できれば、予期せぬ行動一つで重大な攻撃を招く可能性があります。そのため、利用方法が不明でも見つかった欠陥は修正すべきです。第三者による不正利用のリスクは常に存在します。

一般的に、ロジックの欠陥の影響は、その欠陥がどのサービスにあるかに依存します。例えば、検証部分に問題があれば全体のセキュリティに直結する恐れがあります。攻撃者はこれを認証強化や検証の回避、不正な方法で機密情報やサービスにアクセスするために悪用する可能性があり、結果として攻撃の可能性が広がります。

また、ロジックの欠陥が直接的な利益をもたらさなくても、悪意ある第三者が何らかの形でビジネスに損害を与える可能性は十分にございます。

‍

ビジネスロジックの欠陥の検証方法

1. チェック時と利用時のタイミングや競合状態の問題を確認する

• 複数のリクエストを同時に発行して、ウェブアプリのセキュリティを確認する
• カートに安価な商品と高価な商品をそれぞれ追加した状態でページを表示し、安価な商品のページで取引を実行、また高価な商品に影響が及んでいないか確認する
• 支払い完了後に注文内容を変更する

2. 境界値操作

• 価格操作
• 通貨操作（例：USD/EURが使用されている場合、INRに変更してみる）
• 数量操作（例：小数で0.01などの値を入力する）
• レスポンス操作
• リプレイ攻撃

3. 隠蔽された・安全でないバックエンドのAPIセキュリティ
4. 本番環境でテストデータを使用する

ビジネスロジック攻撃のトップ10ベクトル

1. 認証フラグと権限昇格

概要：

各アプリには独自のアクセスコントロールリスト（ACL）と権限が存在します。セキュリティの最も基本的な機能は認証であり、認証された利用者はログイン領域の背後にある内部ページや機能にアクセスできます。これらの権限はデータベース、LDAP、ファイルなどで管理されていますが、認証の実装が脆弱な場合、潜在的な欠陥が生じる恐れがあります。これらの欠陥がテストで発見されれば、不正アクセスによって他の利用者の情報に触れたり、より高い権限を持つ利用者になって重大な被害をもたらす可能性があります。

この欠陥を確認するための最善の方法：

• プロファイリング段階またはプロキシを通して、HTTPリクエストとレスポンスのデータを確認する
• POST/GETリクエストには、名前と値のペア、JSON、XML、またはCookieによる境界が設定されているため、名称と値を解析する
• もし境界名にACLや権限に関連する疑いがあれば、それを標的とする
• 対象が特定されたら、値の検証を行う。値が十六進数や、0/1、文字列などでエンコードされている場合、変更を加えその挙動を観察する
• 例えば、1を0に、またはYをNに変更するなど、一定のパターンで値を調整し挙動を確認する。不正アクセスや権限昇格、認証バイパスが発生すれば、リスクが確認されたことになる

2. ‍重要パラメータの操作と不正情報・コンテンツへのアクセス

概要：

HTTPのGETおよびPOSTリクエストには、通常、名前と値のペア、JSON、XMLなどの境界が設定されています。これらは容易に改ざんや予測の対象となるため、もしアプリのビジネスロジックがこれらの値を十分に検証せずに処理してしまうと、情報やコンテンツが漏洩する可能性があります。これは悪用しやすい一般的なビジネスロジックの欠陥の一つです。

この欠陥を確認するための手順：

• プロファイリング段階またはプロキシを通じ、HTTPリクエストとレスポンスを確認する
• POST/GETリクエストに設定された通常の境界（名前と値のペア、JSON、XML、Cookieなど）を解析する
• すべての境界の値を確認し、連番や推測可能な値がないか調査する
• 値を変更することで不正アクセスが可能かどうか検証する

上記の例では、他の利用者のプロフィールにアクセスできる可能性が確認されました。

3. 開発者が設定したCookieの改ざんと、ビジネスプロセス・ロジックのバイパス

概要：

HTTPでは状態管理のためにCookieが欠かせません。多くの場合、開発者はセッションCookieではなく、内部で独自の値を使用しています。アプリ設計時に重要なタイミングで新たなCookieが設定されることがあり、そこに脆弱性が潜む場合があります。認証ロジックで権限に応じたCookieが設定された後、Cookieをセッションやアプリ内部に設定する方法は2通りあり、もしそのまま値を渡している場合、予測可能な値となり悪用される恐れがあります。攻撃者がこの隙を見つけば、容易に悪用される可能性があります。

この欠陥を確認するための手順：

• プロファイリング段階またはプロキシを通じ、HTTPリクエストとレスポンスを確認する
• プロファイリング中に送信されたすべてのCookieを検査する。中には、開発者が設定したもので、ウェブアプリのセッションCookieでないものもある
• 各Cookieの値を詳細に確認し、連番や推測可能な値がないか調査する
• Cookieの値を変更し、不正アクセスまたは権限昇格が可能か検証する

4. LDAPパラメータの識別と重要インフラへのアクセス

概要：

LDAPは大規模アプリにおいて重要な役割を果たし、シングルサインオンとも連携されることがあります。Site Minderやロードバランサーなど、多くの基盤システムは認証と承認にLDAPを利用しています。LDAPの値はビジネスロジック内で使われることがあり、これが適切に処理されないと悪用される恐れがあります。アプリが十分な検証を行っていなければ、LDAPインジェクションやビジネス層のバイパスが可能となる場合があります。

この欠陥を確認するための手順：

• プロファイリング段階またはプロキシを通じ、HTTPリクエストとレスポンスを確認する
• POST/GETリクエストに設定された通常の境界（名前と値のペア、JSON、XML、Cookieなど）を解析する
• 境界とその値を調査し、「ON」「CN」「DN」など、LDAPに関連するものを探す。同様に、メールやユーザー名を扱う境界にも注目する
• これらの対象となる値を「*」やORなどのLDAP用オペレーターで変更し、認証バイパスや権限昇格が発生するか検証する

5. ‍ビジネス制約の悪用

概要：

アプリのビジネスロジックは、本来の運用に必要なルールや制約を設けています。これらの制約が攻撃者によって回避されると、不正利用が可能となります。利用者の操作が設計や実装ミスにより制限されている場合、隠し属性を用いて情報が漏洩したり、改ざんが発生する恐れがあります。アプリを詳細に解析することで、こうした隠しフィールドや入力箇所を特定でき、値を操作することでビジネスルールを回避できる場合、欠陥として確認されます。

この欠陥を確認するための手順：

• プロファイリング段階またはプロキシを通じ、HTTPリクエストとレスポンスを確認する
• POST/GETリクエストに設定された通常の境界（名前と値のペア、JSON、XML、Cookieなど）を解析する
• 隠された境界とその値を調査し、取引金額や最大制限など、ビジネスルールに関係する項目を探す
• これらの値を変更することで、ビジネスルールを回避し、不正な取引が実行可能か検証する

6. ‍ビジネスフローのバイパス

概要：

アプリはリダイレクトやページ遷移により制御されたフローを持っています。例えば、正常にログインすると利用者は決済ページに移動され、セッションCookieなどで状態が管理されます。しかし、このフローを迂回することでエラー状態や情報漏洩が発生し、バックエンドの重要な情報が明らかになる可能性があります。状況によっては、他のケースでも悪用される恐れがあります。

この欠陥を確認するための手順：

• プロファイリング段階またはプロキシを通じ、HTTPリクエストとレスポンスを確認する
• POST/GETリクエストに設定された通常の境界（名前と値のペア、JSON、XML、Cookieなど）を解析する
• ショッピングカートや送金機能など、明確に実装されたビジネス機能を特定する
• 隠し属性やJavaScriptで追加された潜在的な境界を慎重に調査する
• 取引中にプロキシを介してこれらの値を変更し、フローが乱れて一部のビジネスルールが回避されるか確認する

7. ‍クライアント側のビジネスロジックの悪用（JavaScript、Flash、Silverlight）

概要：

多くのビジネスアプリは、JavaScript、Flash、Silverlightを利用したリッチウェブアプリ上で動作しており、ロジックの大部分がクライアント側に実装されています。FlashやSilverlightの場合、コードを逆コンパイルして実際のロジックを解析可能です。JavaScriptの場合も、コードを行ごとに確認することで、埋め込まれたロジックや計算処理、認証情報の格納、権限チェックなどが明らかになり、さらなる不正行為につながる脆弱性が発見される恐れがあります。

この欠陥を確認するための手順：

• ページが読み込まれた後、Firebugなどのツールを用いてDOMを確認する
• アプリ内で使用されているすべての要素を特定する
• 疑わしい値や境界がないか調査する
• DOM内の値を変更し、HTTPリクエストを再送信して挙動を確認する

もしビジネスロジックがクライアント側のみで完結していれば、不正アクセスが可能となる恐れがあります。

8. ‍IDまたはプロフィールの抽出

概要：

認証されたアプリでは、利用者のIDは最も基本的な境界の一つです。利用者の情報はセッションなどのトークンで管理されていますが、設計や実装が不十分な場合、攻撃者がクライアント側からこれらの値を取得し、サーバ側でも十分に管理されていない場合があります。これにより、不正利用やシステム全体での不正行為のリスクが高まります。トークンが単純な連番や推測可能なユーザー名であれば特に危険です。

この欠陥を確認するための手順：

• プロファイリング段階または特定のプロキシを通じ、HTTPリクエストとレスポンスを確認する
• POST/GETリクエストに設定された通常の境界（名前と値のペア、JSON、XML、Cookieなど）を解析する
• プロフィール管理に関連すると思われる境界を探し、該当する場合はトークンの推測や再生成が可能か確認する

9. ‍ファイルまたは不正なURLアクセスによるビジネス情報の抽出

概要：

ビジネスアプリは、利用者の基本情報、取引履歴、サービスそのものなどの重要なデータを含んでいます。利用者はこれらの情報をPDF、XLS、CSVなどの形式で出力し、ダウンロードできる場合があります。実装が不十分だと、情報漏洩のリスクが発生し、攻撃者はアプリ層から重要なデータを抽出できる可能性があります。これはよく知られた欠陥であり、悪用も容易です。これらのファイルは直接URLにアクセスするか、内部の境界を利用して取得される可能性があります。

この欠陥を確認するための方法：

• プロファイリング段階または特定のプロキシを通じ、HTTPリクエストとレスポンスを確認する
• POST/GETリクエストに設定された通常の境界（名前と値のペア、JSON、XML、Cookieなど）を調査する
• document、doc、dirなど、ファイルアクセスに関連する境界名を特定し、そこから不正アクセスの可能性を検討する
• 対象の境界が確認された場合、ブルートフォースや推測手法を用いて他の利用者のファイルにアクセスできるか試す

10. ‍ビジネスロジックを利用したDoS攻撃

概要：

DoS (Denial of Service) の脆弱性は、アプリが長時間または一部の機能を停止する可能性があるため、ビジネスアプリにとって重大です。多くのコンポーネントは、適切に実装されていないとDoS状態を引き起こす要因となります。場合によっては、設計自体にDoS攻撃のリスクがあることもあり、またレースコンディションがDoS脆弱性を助長する場合もあります。アプリ層ではTCPフラッディングのような一律の攻撃は存在しませんが、コンポーネントやアプリにより、無限ループなどがDoS攻撃を引き起こす可能性があります。

この欠陥を確認するための方法：

TCPフラッディングのような一律のDoS攻撃は存在しませんが、コンポーネントやアプリによっては、アプリ層での無限ループがDoS攻撃を引き起こす可能性があります。