※本記事にはアフィリエイトリンクが含まれています。
今回解説するのは、Web Security Academyのラボ 「Insufficient workflow validation」 です。
このラボでは、ECサイトの購入フローにある処理順序のチェック不足を悪用して、本来は購入できない商品を無料で購入できてしまいます。
一見すると正常に動いているように見える購入システムでも、処理の順番を正しく検証していないと簡単に突破されることがあります。
この記事では、
- 何が起きるのか
- なぜ起きるのか
- WordPressサイトで起きるとどうなるのか
という順番で解説します。
ビジネスロジック脆弱性は、XSSやSQLインジェクションのような典型的な脆弱性とは少し性質が異なります。
しかし、Webアプリケーションの基本的なセキュリティ知識を理解しているとこうした設計ミスにも気づきやすくなります。
Webセキュリティの基礎を体系的に学びたい場合は、この本が定番です。
ECサイトで商品が無料になる？Insufficient workflow validationとは
このラボでは、ECサイトの購入処理に問題があります。
通常、商品を購入する流れは次のようになっています。
- 商品をカートに入れる
- 支払い処理を行う
- 注文を確定する
しかしこのサイトでは、注文確定ページに直接アクセスすると購入処理が完了してしまいます。
その結果、本来は買えない高額商品を無料で購入することができます。
Insufficient workflow validationの攻撃の流れ
攻撃者は、購入処理の途中にある「注文確認ページ」を直接呼び出します。
商品をカートに入れる
↓
購入処理を途中まで実行
↓
注文確認URLを直接アクセス
↓
支払い処理をスキップして注文完了
このように、本来通るべき処理を飛ばして注文を完了させることができてしまうのです。
なぜ支払いをスキップできてしまうのか
この問題の原因は、購入処理の順番をサーバー側で確認していないことです。
本来は次のようなチェックが必要です。
- 支払いが完了しているか
- ユーザーの残高が減っているか
- 注文フローを正しく通過しているか
しかし、このラボでは、「注文確認ページが呼ばれたら注文完了」というシンプルな処理になっています。
そのため、攻撃者は 支払い処理をスキップして注文を確定できてしまいます。
Insufficient workflow validationの意味
「Insufficient workflow validation」は直訳すると、ワークフロー検証不足という意味です。
ここでいうワークフローとは処理の流れ（手順）のことです。
つまりこのラボは、処理の順番が正しいか確認していないことが原因で起きる脆弱性です。
なぜこれはビジネスロジック脆弱性なのか
この問題は、
- SQLインジェクション
- XSS
- CSRF
のような技術的なバグではありません。
問題なのは、システムの設計ルールそのものです。
ECサイトの設計では、
- 支払い
- 注文確定
という順番が必ず守られる必要があります。
しかし、このラボでは、順番を守らなくても注文できるという設計ミスがあります。
このような、システムのルールの穴を突く攻撃をビジネスロジック脆弱性と呼びます。
WordPress（WooCommerce）で起きた場合の具体例
WordPressでも、ECプラグインを使うと同じ問題が起きる可能性があります。
たとえば、WooCommerceを使ったサイトです。
本来の購入フローは次のようになります。
【WordPressでの購入フロー】
商品ページ
↓
カート
↓
チェックアウト
↓
支払い処理
↓
注文完了
このとき、もし次のような設計になっていたら危険です。
【支払い確認がない場合】
チェックアウト
↓
注文完了ページ
↓
注文登録
この設計だと、注文完了URLに直接アクセスするだけで購入が成立する可能性があります。
たとえば、以下のようなURLです。
/checkout/order-received/
もしサーバー側で、支払い完了や決済成功を確認していないと、無料注文が成立する可能性があります。
WordPressでの対策ポイント
ECサイトでは次のチェックが重要です。
まず、注文完了処理をURLだけで実行しないことです。
注文完了ページは、
- 決済成功
- 残高減少
- トランザクション完了
などの条件を満たした場合のみ表示する必要があります。
次に、注文ステータスの確認です。
WooCommerceでは、
- pending
- processing
- completed
などの注文状態があります。
この状態をサーバー側で検証することが重要です。
設計視点で見ると何が問題だったのか
この問題の本質は、画面の流れを信用してしまったことです。
ユーザーは、
- URLを直接開く
- リクエストを改ざんする
- Burpなどで通信を変更する
ことができます。
そのため、画面の流れではなくサーバーの状態を信頼する必要があります。
設計視点で整理する
ECサイト設計では次の点を確認すると安全です。
- 注文完了前に必ず決済成功を確認しているか
- URLアクセスだけで注文確定にならないか
- 購入フローの順番をサーバー側で管理しているか
- 注文状態（pending / paid）をチェックしているか
- 決済結果を外部APIで検証しているか
セキュリティ診断で確認すべきポイント
セキュリティ診断では、次のポイントを確認します。
まず、注文フローを観察します。
次に
- カート
- チェックアウト
- 注文完了
のリクエストをBurpで確認します。
そのうえで、注文完了URLを直接送信してみます。
もし注文が成立した場合は、ワークフロー検証不足の可能性があります。
Insufficient workflow validationのまとめ｜ECサイト購入フローの設計ミスに注意
この記事のポイント
今回のラボでは、ECサイトの購入フローにある設計ミスを利用しました。
問題のポイントは、処理の順番をサーバー側で確認していないことです。
このような問題は、
- ECサイト
- 会員サイト
- ポイントシステム
などでもよく発生します。
画面の流れだけに頼るのではなく、サーバー側で状態を確認する設計が重要です。
よくある疑問
Q. この攻撃は実際のECサイトでも起きますか？
起きることがあります。
特に独自開発のECサイトでは、購入フローの検証不足が原因で無料購入が成立するケースがあります。
Q. WooCommerceでも起きますか？
通常のWooCommerceでは発生しません。
しかし、独自プラグインやカスタム決済を追加すると起きる可能性があります。
Q. なぜURLだけで注文が完了するのですか？
注文完了ページが「注文確定処理」も兼ねている設計の場合、URLアクセスだけで処理が実行されることがあります。
Q. ビジネスロジック脆弱性は自動スキャンで見つかりますか？
見つかりにくいです。
多くの場合、人が購入フローを観察して気づきます。