WordPressで考える Infinite money logic flaw｜クーポンと残高が増殖するロジック脆弱性

今回は、Web Security Academyの 「Infinite money logic flaw」 というラボを解説します。

このラボでは、購入の流れそのものは一見正常に見えるのに、割引されたギフトカードを買って自分で使えるせいで、ストアクレジットが少しずつ増えていく問題を扱っています。

一見すると、10ドルのギフトカードを買って、あとで使うだけに見えます。
しかし、クーポン適用とギフトカード利用の組み合わせ方に問題があると、使うたびにお金が増えるような状態が作れてしまいます。

これはECサイトだけの話ではありません。WordPressやWooCommerceでも、クーポン・ポイント・ギフト券・会員残高の設計が甘いと、同じような事故が起こりえます。

ラボ「Infinite money logic flaw」の概要

このラボでは、ログイン後にニュースレター登録を行うと、SIGNUP30という30％オフのクーポンが手に入ります。

そしてサイト内では、10ドルのギフトカードを購入できます。
さらに、そのギフトカードは My accountページで自分のストアクレジットに交換 できます。

ここで問題になるのは、次の流れです。

• 10ドルのギフトカードを買う
• クーポンで30％オフにする
• 7ドルで購入する
• そのギフトカードを自分で使って10ドル分の残高に変える

これで、1回あたり 3ドル分だけ残高が増える ことになります。

この処理を何度も繰り返すと、元手以上のストアクレジットが増え続け、最後には本来買えない高額商品まで買えるようになります。
ラボでは、この方法で 「Lightweight l33t leather jacket」 を購入するとクリアです。

攻撃の流れ｜割引購入でストア残高が増える仕組み

このラボの攻撃は、難しいコード実行というより、正しい機能を正しい順番で悪用するタイプです。

まず攻撃者は、ニュースレター登録で30％オフのクーポンを取得します。
次に、10ドルのギフトカードをカートに入れ、クーポンを適用して7ドルで購入します。
その後、発行されたギフトカードコードを自分のアカウントでredeem（残高化）します。すると10ドル分のストアクレジットが加算されます。

つまり、7ドル払って10ドル分の残高を得ているので、差額の3ドルが増えます。
これを自動化して何度も繰り返せば、残高がどんどん増えていきます。

【攻撃の流れ】

クーポン取得
↓
10ドルのギフトカードを30％オフで購入
↓
7ドル支払いで10ドル分のギフトカードを入手
↓
自分のアカウントでギフトカードを残高化
↓
1回ごとに3ドルずつストアクレジットが増える

この図のポイントは、「割引購入」と「額面どおりの残高化」が同時に成立している ことです。
本来この2つは、組み合わせると危険な処理です。

なぜInfinite money logic flawが発生するのか｜業務ルール設計のミス

この問題が起きる原因は、個々の機能は正しく見えても、組み合わせたときの整合性が検証されていない ことです。

ギフトカードの購入機能だけを見ると問題なさそうです。
クーポン機能だけを見ても、割引処理としては普通です。
ギフトカードの利用機能だけ見ても、コードを入力して残高に変えるだけです。

しかし、システム全体として見ると、「割引された自己購入ギフトカードを、自分の残高へそのまま変換できる」 という穴が空いています。

つまり、アプリ側が次のように考えてしまっています。

• クーポンは商品に使える
• ギフトカードも商品として買える
• ギフトカードは額面どおり使える
• それを自分で使っても問題ない

この前提を全部まとめると、お金を増やせるループになります。

これは金額計算ミスというより、業務ルールの設計ミスです。
「どの商品に割引を使ってよいのか」「誰がそのギフトカードを使ってよいのか」「購入価格と利用価値の関係はどうあるべきか」といったルールが、十分に整理されていません。

Infinite money logic flawの意味

「Infinite money logic flaw」は、直訳すると 「無限にお金が増えるロジック上の欠陥」 です。

もちろん本当に現金が湧いてくるわけではありません。
ここでいうmoneyは、サイト内で使える 残高・クレジット・ポイント のような価値を指しています。

つまりこのラボ名は、処理の組み合わせミスによって、サイト内の金銭的価値が増殖してしまう問題という意味です。

初心者目線で言い換えると、「割引とチャージ機能を同時に使ったせいで、残高を増やし放題になっている状態」と考えると分かりやすいです。

なぜこれはビジネスロジック脆弱性なのか

これはSQLインジェクションやXSSのような、入力欄に変な文字を入れて壊す攻撃ではありません。

サイト運営側が決めた販売ルールそのものに問題があります。

ビジネスロジック脆弱性とは、ざっくり言うと「業務上こう動くはず」というルールの作り方に穴がある問題です。

このラボでは、システムが次のような業務判断を誤っています。

• ギフトカードを通常商品と同じように割引対象にしている
• 自分で買ったギフトカードを自分の残高に戻せてしまう
• その結果、購入より利用価値のほうが高くなっている

技術的には正常に動いていても、商売のルールとして破綻しているので、これは典型的なビジネスロジック脆弱性です。

WordPress、WooCommerceで起こるInfinite money logic flawの具体例

WordPress、特にWooCommerceでは、このラボにかなり近いことが起こりえます。

たとえば、WooCommerceで次のような設定をしていたとします。

• 1,000円分のギフト券商品を販売している
• 新規登録クーポンで30％オフになる
• 購入したギフト券コードを、マイページでポイントや残高に交換できる
• しかも自分で買ったギフト券も自分で使える

この場合、700円で買ったギフト券を1,000円分の残高として使えてしまいます。
これを何度も繰り返されたら、ショップ側はその差額ぶん損をします。

会員サイトでも似たようなことがあります。

たとえば、

• 有料会員向けに「紹介特典コード」を発行する
• そのコードを自分でも使える
• 使うとポイント残高が増える
• そのポイントでさらに同じ仕組みを回せる

という形だと、やはり価値が増えてしまいます。

【攻撃の流れ】

WooCommerceでギフト券を販売
↓
新規登録クーポンで割引購入
↓
購入したギフト券を自分のマイページで残高化
↓
支払額より多い価値がアカウントに入る
↓
その差額を何度も積み上げて高額商品を購入される

この図で大事なのは、WooCommerceの1機能が危険なのではなく、機能同士のつなぎ方が危険という点です。
クーポン、ギフト券、ポイント、会員残高は、組み合わせると事故になりやすいです。

WooCommerceでInfinite money logic flawを防ぐ対策ポイント

まず一番大事なのは、ギフトカードやチャージ系商品を割引対象から外すことです。

これだけでも、かなり危険度が下がります。
なぜなら、安く買った価値を満額で残高化できる状態を防ぎやすいからです。

次に、自分で購入したギフトカードを自分では使えないようにするのも有効です。
本来ギフトカードは誰かに渡す前提のことが多いので、自己利用を許すなら慎重な設計が必要です。

さらに、次のような制御も重要です。

• ギフトカード購入時にクーポン利用不可にする
• ギフトカードの利用先を商品購入のみに限定し、残高化させない
• ポイントや残高に変換する際に、元の購入額や取得経路を確認する
• 異常な短時間連続購入を検知する
• 同じユーザーが繰り返し価値交換していないか監視する

WooCommerceでは、標準機能だけで完全に防げない場合があります。
その場合は、使っているギフト券系プラグインやポイント系プラグインの仕様を確認し、必要なら購入制限やクーポン制御を追加実装することが必要です。

設計視点で見ると何が問題だったのか

このラボの本当の問題は、「1つ1つの画面」ではなく「価値の流れ全体」を見ていなかったことです。

開発中は、次のように個別チェックしがちです。

• クーポンはちゃんと割引されるか
• ギフトカードはちゃんと発行されるか
• ギフトカードはちゃんと使えるか

でも、それだけでは足りません。

重要なのは、

割引前の価値
割引後の支払額
交換後の価値

が、ぐるっと1周したときにどうなるかです。

このラボでは、その1周をすると価値が増えてしまいます。
つまり、システム全体で見たときに収支がマイナスではなくプラスになってしまっているのです。

設計の言い方をすると、価値保存のルールが崩れているということです。

ビジネスロジック脆弱性を防ぐ設計チェックリスト

• 割引クーポンは、ギフトカードやチャージ商品にも使えてしまわないか
• 購入したコードやチケットを、自分自身の残高へ戻せてしまわないか
• 支払額より大きい価値を、別の形で受け取れる流れがないか
• ポイント・残高・クーポン・ギフト券を組み合わせたとき、1周して価値が増えないか
• 単発テストだけでなく、同じ処理を連続実行した場合も破綻しないか

セキュリティ診断時のチェックポイント

診断時は、単に「割引できるか」だけで終わらせず、価値交換ループを探すのが重要です。

たとえば次の視点で確認すると見つけやすいです。

• クーポン対象外にすべき商品が割引されていないか
• ギフト券、ポイント、紹介報酬、会員残高の相互変換がないか
• 取得した特典を自分自身へ再投入できないか
• 購入後のメールや確認画面で発行されたコードを、そのまま別機能で使えないか
• 一度の処理では小さな差額でも、繰り返すと利益になる流れがないか

Burp Suiteで見るなら、購入完了レスポンスに出るコードと残高追加リクエストのつながりを確認すると分かりやすいです。
WooCommerce系サイトなら、注文完了後メール、マイページのクーポン入力欄、ポイント履歴、ストアクレジット反映処理などが確認ポイントになります。

まとめ｜ECサイト設計の注意点

「Infinite money logic flaw」は、割引・購入・残高化という別々の正常機能を組み合わせた結果、価値が増えてしまう脆弱性 です。

この手の問題は、画面単位で見ていると気づきにくいです。
しかし、ECサイトや会員サイトでは非常に危険です。なぜなら、攻撃者にとっては「システムの穴を使って残高を増やす方法」になってしまうからです。

WordPressやWooCommerceでも、ギフト券、ポイント、紹介コード、クーポンを併用しているサイトでは、同じような設計ミスが起こりえます。

見るべきなのは、その機能が動くかどうかではなく、その機能を組み合わせたときに不正な利益が出ないかです。

よくある疑問