Web Security Academyのラボを、WordPress視点で整理してみたシリーズ～ビジネスロジック脆弱性編～第1弾。
今回は、ラボ「Excessive trust in client-side controls」を題材に考察します。
このラボでは、HTTPリクエストを書き換えるだけで商品の価格を変更し、本来は購入できない商品を不正な価格で購入することができてしまいます。
WSAラボ「Excessive trust in client-side controls」の概要
このラボでは、クライアント側の入力制御を過信していることによって、価格制限を回避できてしまう問題を扱います。
本来、このストアでは$100以上の商品は購入できないという制限があります。
しかし、購入時に送信されるHTTPリクエストを直接編集することで、この制限を回避できます。
攻撃の流れーー価格改ざんはどのように成立するのか
まず、このラボで起きている攻撃の流れを簡単に整理してみます。
このラボでは、価格制限を回避するためにリクエストが改ざんされます。
実際の流れを簡単に整理すると次のようになります。
画面：$100以上の商品は購入できない
↓
送信：price=1337
↓（Burp Suiteで改ざん）
改ざん：price=10
↓
サーバー：priceを再検証せず処理
↓
結果：不正価格で注文が成立
ブラウザ画面では価格が固定されているように見えても、HTTPリクエストの値を書き換えるだけで結果が変わるのがポイントです。
なぜ価格改ざんが成立するのかーークライアント側検証の問題
この問題が起きる理由はシンプルです。サーバーが送信された価格を信用していたからです。
開発者は次のように考えてしまうことがあります。
- 画面で価格は固定されている
- JavaScriptで数量制限をしている
- 入力欄はユーザーが変更できない
しかしブラウザの画面はあくまで表示にすぎません。
ブラウザは最終的にHTTPリクエストというデータをサーバーへ送信します。
このリクエストはBurp Suiteなどのツールを使えば簡単に編集できます。
つまり攻撃者はブラウザの制限を無視して、送信データだけを書き換えることができます。
そのためセキュリティの世界では次の原則がよく言われます。
Never trust client input
（クライアント入力を信用するな）
重要なデータは必ずサーバー側で再検証する必要があります。
ラボ名「Excessive trust in client-side controls」の意味
ラボ名の「Excessive trust in client-side controls」を直訳すると「クライアント側制御への過度な信頼」という意味です。
- Excessive：過度な
- trust：信用
- client-side：ブラウザ側
- controls：入力制御
ここでいう controls は、ボタンやUIの見た目だけでなく、数量制限や価格制御などの入力ロジック全体を指しています。
つまりこのラボは「ブラウザ側で制御しているから安全だ」という設計上の思い込みが問題になることを示しています。
本来、重要な処理は必ずサーバー側で検証する必要があります。
なぜこれはビジネスロジック脆弱性なのか
この問題はSQLインジェクションやXSSのような入力処理のバグではありません。問題はアプリケーションの設計そのものです。
開発者は「ユーザーは画面通りに操作する」「価格は変更できない」「数量制限は守られる」という前提でシステムを作っていました。
しかし実際にはHTTPリクエストは自由に編集できます。
つまり、「ユーザーは想定通りに行動する」という前提が崩れたことで、購入フローそのものが破綻しました。
このような設計上の欠陥はビジネスロジック脆弱性に分類されます。
WordPress（WooCommerce）で起こり得る価格改ざんの例
WordPress本体では発生しにくいものの、WooCommerceなどのECプラグインや独自開発された購入機能では同様の問題が起こる可能性があります。
例えば次のような実装です。
- JavaScriptで数量制限をしているだけ
- hiddenフィールドに価格を保持している
- Ajax通信で送信された価格をそのまま処理している
このような場合、リクエストを書き換えられれば不正価格で注文が成立する可能性があります。
実際のECサイトでも、クライアント側価格を信用した実装による価格改ざんの事故は過去に報告されています。
安全な設計では、商品IDを受け取ったあとサーバー側でデータベースから価格を取得し、数量や合計金額を再計算する必要があります。
ECサイト診断で確認すべきポイント
ECサイトを診断する際には、次の点を確認します。
- priceをクライアント入力のまま使用していないか
- hiddenフィールドの値を信用していないか
- Ajax通信のパラメータを検証しているか
- サーバー側で価格を再取得しているか
画面で制限されていることと、安全であることは別問題です。
まとめーークライアント入力を信用しない設計が重要
今回のラボは「クライアント側制御を過信する危険性」を示しています。
ブラウザ画面では価格が固定されていても、HTTPリクエストを書き換えれば値は変更できます。
そのため重要なデータは必ずサーバー側で再計算・再検証する必要があります。
WordPressサイトでも、EC機能やカスタム購入機能を実装する場合は「クライアント入力を信用しない設計」を前提にすることが重要です。
今後もWeb Security AcademyのラボをWordPressの実例に置き換えながら、ビジネスロジック脆弱性を整理していきます。
よくある疑問
価格改ざんとは何ですか？
価格改ざんとは、商品の価格を不正に変更して購入する攻撃のことです。
例えばHTTPリクエストに含まれる price パラメータを書き換えることで、本来より安い価格で注文できてしまう場合があります。
クライアント側検証とは何ですか？
クライアント側検証とは、ブラウザ側（JavaScriptなど）で入力値をチェックする仕組みのことです。
例えば「数量は1〜5まで」といった制限を画面上で行う処理がこれに当たります。
ただし、HTTPリクエストはツールで書き換えることができるため、クライアント側検証だけではセキュリティ対策として不十分です。
なぜクライアント入力を信用してはいけないのですか？
ブラウザから送信されるHTTPリクエストは、攻撃者が自由に編集できるためです。
そのため重要なデータ（価格・権限・数量など）は、必ずサーバー側で再検証する必要があります。
WooCommerceでも価格改ざんは起こりますか？
WooCommerce本体はサーバー側で価格を計算する設計になっているため、基本的には安全です。
しかしカスタムプラグインや独自実装でクライアント側の値をそのまま使用すると、同様の問題が発生する可能性があります。