診断するとなんだかんだ検出されるシリーズ：ビジネスロジックエラー：2025/02/21
- 晋次 宮田
- 2025年2月21日
- 読了時間: 4分
はじめに
なんだかんだどころか、Webアプリケーションの脆弱性診断をしていると、ビジネスロジックエラーの脆弱性が、必ずと言っていいほど見つかります。
今回は、ビジネスロジックエラーがどんな仕組みで発生し、なぜ見つかるのか、そしてどのように防げるのかを、実例を交えながら解説してみます。
1. ビジネスロジックエラーとは？
ビジネスロジックエラー（Business Logic Flaw）とは、アプリケーションが備えるビジネスルールや業務フローに内在する抜け穴を攻撃者に突かれてしまう脆弱性のことです。
特徴: SQLインジェクションやXSSのように「コードの入力チェックミス」を突くのではなく、“本来あるべき処理フロー”を回避したり、“一見正常に見える入力”を悪用することで機能をハイジャックする点が特徴。
自動スキャナでは見つかりにくい、というかほぼ見つからないです。
事例１：割引コードの不正利用
ECサイトで「同じ割引コードを何度でも適用できてしまう」という致命的な例があります。通常は1回きりのはずなのに、サーバ側でのチェックが甘く、POSTデータを少し変えるだけで何度も使えてしまう。
結果: 攻撃者は“ほぼ無料”で何度も商品を購入できてしまう、運営側に大きな損害が出る恐れがある——まさにビジネスロジックエラーです。
2. 診断でビジネスロジックエラーが必ず見つかる理由
権限管理の抜け漏れ
本来アクセスできないはずの操作が、POSTデータやCookieの改ざんで実行できてしまう。
例えば“一般ユーザー”が、リクエスト中の権限パラメータをadminに書き換えるだけで管理者機能を使えてしまうなど。
POSTデータやCookieの改ざんはみなさんが考えているより容易だと思ったほうが良いです。ツールを使えば小学生でも可能です。
フロントエンド制御への過度な依存
「UI上でボタンやフォームを非表示にすればOK」という安易な実装。安易というか、確信犯だと思うので、やる気のない実装ですね。
攻撃者はツールなどで直接リクエストを編集し、目に見えない機能を使うあるいは不正な値を送ることができます。
ロールが多いとテストが複雑に
大規模システムだと、「代理店」「管理者」「マネージャー」「スーパーユーザー」など多数のロールを運用するケースがあります。
全ロール×全機能のテストを網羅しきれず、あるロールだけ想定外の機能が使えるなど、抜け道が残ってしまうのです。でもこれはある程度仕方ないと思ってはいます。ロールが増えるとパターンが二次曲線的に増えるので。
想定外の悪用シナリオ
一般的な使い方しかテストしていないと、例えば「購入フローを途中で飛ばす」「在庫数にマイナス値を入れる」といった“不自然な操作”がカバーされません。
攻撃者はこうした非常識な手法を積極的に試すため、ロジックの甘さを見つけ出します。（そんな攻撃をしている暇があるならまともに働けばいいのに）
3. ビジネスロジックを突かれた脆弱性の具体的事例
事例２：一般ユーザーが管理者になれた
状況: ユーザー種別をCookieのuserTypeパラメータで管理。
攻撃: 一般ユーザーでログイン後、CookieのuserType=userをadminに書き換えて送信。
結果: 管理者画面がアンロックされ、重要機能（データ削除・アカウント管理など）が自由に使えてしまった。
この例は「画面に管理者用リンクが表示されない」だけで安心していたパターンです。しかしサーバサイドで“本当に管理者かどうか”をチェックしていなかったため、深刻な権限昇格が起きてしまいました。
嘘のような実装例ですが、お客さんいわく「SIerさんに発注して作ってもらったのでよくわからない」とのことでした。情報システム部が無い場合、要求仕様をしっかりと作り込めないので、「良くも悪くもシステムベンダーさん次第」になっちゃう良い事例です。
4. 対策：どう守るか？
4-1. ちゃんと作る（もしくはちゃんと作ってもらうように要求する）
RBAC（Role-Based Access Control）を導入し、各ロールに対して利用可能な操作を明確に定義し、APIごとに必ず認可チェックを行いましょう。
4-2. 不正な改ざん検知・署名付きトークンの利用
Cookieやトークンを使う場合は、JWT（JSON Web Token）などを活用して、改ざんを署名で検知できる仕組みにするのが有効です。
サーバ側で改ざんリクエストが来た場合は即座に弾くなど、クライアントサイドに頼らない防御を心がけましょう。
4-3. 上流工程で頭に汗をかく
要求整理・要件定義でロールを詰めきる努力をしておかないと、あとからロールを必要以上に細かくする必要がでてくることになります。その結果「このロールでこれはOKだけどこれはNG」といった複雑な条件が増えてテストが抜けやすくなります。
権限マトリクスを作って一元管理し、定期的に棚卸しやレビューを行うことも重要です。
4-4. ペネトレーションテストをする
自動スキャナでは検出困難なケースが多いため、手動での診断が大切です。
そうです宣伝です。ビジネスロジックエラーの検出は我々の超得意とする領域です。
