今回は、Web Security Academyの「Authentication bypass via flawed state machine」 というラボを解説します。
このラボでは、ログイン処理の順番の設計ミスによって、本来ログインできないはずのユーザーが管理者権限を取得できてしまう脆弱性を扱っています。
一見するとログイン機能は正常に見えます。
しかし内部の処理順序に問題があり、攻撃者がその流れを崩すことで認証をバイパス（回避）できます。
WordPressでも同じような設計ミスが起きる可能性があるため、仕組みを理解しておくことは非常に重要です。
まず、このラボでどのような問題が起きているのかを整理してみます。
Authentication bypass via flawed state machineとは
ラボ名の「Authentication bypass via flawed state machine」は、「状態遷移の設計ミスによって認証を回避できる」という意味です。
ここでポイントになるのがstate machine（状態遷移） です。
Webアプリケーションの多くの処理は、
ログイン
↓
権限確認
↓
ページ表示
のように、決められた順番で処理が進むように設計されています。
しかし今回のラボでは、ログイン後に実行されるはずのrole-selectorの処理をスキップできてしまいました。
その結果、ユーザー権限が決まっていない状態のまま処理が続き、最終的にadministrator権限が付与されてしまいます。
つまりこのラボは、ログイン処理の順番に依存した設計が破られることで、認証を回避できてしまう脆弱性を扱っています。
認証バイパスの攻撃手順｜role-selectorをスキップして管理者になる方法
ログイン
↓
role-selector リクエストを送信する
↓
攻撃者がリクエストを削除
↓
権限が未設定の状態になる
↓
デフォルト値として administrator が付与される
このラボではBurp Suiteを使い、GET /role-selector のリクエストを削除することでこの状態を作ります。
その後ホームページへアクセスすると、管理者としてログインした状態になります。
なぜログイン処理の順番ミスで認証バイパスが起きるのか
この脆弱性が起きる原因は、ログイン処理の設計ミスです。
今回のサイトでは、ログイン処理が次の順番で進むことを前提に作られていました。
ログイン
↓
role-selector
↓
ユーザー権限決定
↓
ホーム画面
つまり開発者は、「ユーザーは必ずrole-selectorを通る」と考えてシステムを設計していました。
しかし実際のWebアプリケーションでは、攻撃者がリクエストを操作することができます。
例えば Burp Suite を使うと、
- リクエストを削除する
- リクエストの順番を変える
- URLへ直接アクセスする
といった操作が可能です。
今回のラボでは、攻撃者が GET /role-selector のリクエストを削除しました。
するとシステムは、ユーザー権限が決まっていない状態のまま処理を続けてしまい、結果として administrator 権限が付与されてしまいました。
つまりこのシステムでは、ユーザー権限が設定されていない場合のデフォルト値が administrator になっていました。
本来は「権限未設定の場合はアクセス拒否」にするべきでしたが、その設計になっていなかったことが問題です。
状態遷移（State Machine）の設計ミス
このような問題は、セキュリティの分野ではState Machine（状態遷移）の設計ミスと呼ばれることがあります。
State Machineとは、システムの処理が、
ログイン
↓
権限確認
↓
ページ表示
のように、決められた順番で状態が変化していく仕組みのことです。
Webアプリケーションでは
- ログイン処理
- 購入処理
- 会員登録
- パスワードリセット
など、ほとんどの機能がこの状態遷移で動いています。
しかし開発者が、「ユーザーは必ずこの順番で操作する」という前提で設計していると問題が起きます。
攻撃者は、
- URLを直接開く
- リクエストを削除する
- リクエストの順番を変える
といった操作ができるため、処理の順番だけに依存した設計は非常に危険です。
安全な設計では、
ページアクセス
↓
ユーザー権限を確認
↓
表示 / 拒否
のように、処理のタイミングごとに状態を確認する必要があります。
Authentication bypass via flawed state machineの意味
「Authentication bypass via flawed state machine」
意味を分解すると次の通りです。
Authentication bypass - 認証を回避する
flawed - 欠陥のある
state machine - 状態遷移（処理の順番）
つまりこのラボは、処理の順番の設計ミスによって認証を回避できる脆弱性という意味になります。
なぜこれはビジネスロジック脆弱性なのか
この問題は、SQLインジェクションやXSS、CSRFのような技術的なバグではありません。
問題は、ログイン処理の設計です。
システムは、「必ずrole-selectorが実行される」と決めつけて設計されています。
しかし実際のWebでは、
- リクエスト削除
- URL直接アクセス
- 手動リクエスト送信
などが可能です。
つまり、ユーザーは開発者が想定した順番で操作するとは限らないという点がビジネスロジック脆弱性の本質です。
WordPress（WooCommerce）で起きるとどうなるか│ログインフロー設計ミスの具体例
WooCommerceのECサイトでは、商品を購入するまでにいくつかのステップを順番に進む必要があります。
通常の購入の流れは次のようになっています。
商品をカートに追加
↓
チェックアウトページ
↓
住所入力
↓
支払い処理
↓
注文確定
この流れの中で、WooCommerceは、
- 商品価格の計算
- クーポンの適用
- 在庫確認
- 支払い処理
などを行っています。
設計に問題がある場合
もしシステムが「必ずこの順番でページが開かれる」という前提で作られていると問題が起きます。
例えば開発者が、「チェックアウトページを通ったら支払い処理は済んでいるはず」と考えて設計していたとします。
しかし攻撃者がURLを直接操作して、途中のページをスキップするとどうなるでしょうか。
【フロー】
商品ページ
↓
チェックアウトページ
↓
支払い処理
↓
注文確定
この流れが正常な購入フローです。
しかし攻撃者がリクエストを操作すると、
商品ページ
↓
途中の処理をスキップ
↓
支払い確認が行われない
↓
注文処理が進んでしまう
という状態になる可能性があります。
なぜ今回のラボと同じ構造なのか
今回のラボでは、
POST /login
↓
GET /role-selector
↓
ホーム画面
というログインフローがありました。
しかし攻撃者は、role-selector のリクエストを削除しました。
その結果、
role未設定
↓
administrator がデフォルト
になり、管理者としてログインできました。
つまり問題の本質は、「途中の処理に依存して権限や状態を決めていること」です。
WooCommerceでも、
- 住所入力
- 支払い確認
- クーポン検証
などの処理を途中のページに依存していると、同じような問題が起きる可能性があります。
WooCommerceで認証バイパスを防ぐための対策
このような問題を防ぐには、処理の順番ではなく状態をチェックすることが重要です。
安全な設計では、
注文確定
↓
支払い済みか確認
↓
注文完了
のように、最終処理の時点で必ず状態を確認する必要があります。
しかし処理の順番だけを前提に設計すると、
このページを通ったはず
↓
だからOK
という判断になり、攻撃者がその順番を崩すと不正操作が成立してしまいます。
設計視点で見るログイン処理の問題点
このラボの最大の問題は、「ユーザー権限を途中の処理に依存していたこと」です。
安全な設計では、
ページアクセス時
↓
ユーザー権限確認
↓
許可 / 拒否
と毎回チェックする必要があります。
しかしこのラボでは、
role-selector を通ったはず
↓
だから管理画面OK
という前提条件だけで判断していました。
ビジネスロジック脆弱性を防ぐ設計チェックリスト
ビジネスロジック脆弱性を防ぐためのチェックリストです。
- 処理の順番を前提に設計していないか
- URL直接アクセスを想定しているか
- 権限チェックを毎回実行しているか
- セッション値だけに依存していないか
- デフォルト権限が安全な設定になっているか
セキュリティ診断で確認するログインフローのチェックポイント
セキュリティ診断では次のポイントを確認します。
- ログイン後のURLへ直接アクセスできるか
- 中間ページをスキップできるか
- 権限設定はどこで行われているか
- デフォルト権限は何か
- リクエスト削除で状態が変わるか
Burp Suiteを使うと、リクエストを削除して挙動を確認できます。
Authentication bypass via flawed state machineのまとめ
「Authentication bypass via flawed state machine」は、ログイン処理の順番の設計ミスによって認証が破られる脆弱性です。
攻撃のポイントは、
- 中間リクエストの削除
- 状態遷移の破壊
- デフォルト権限の悪用
です。
WordPressでも、
- 会員サイト
- WooCommerce
- 管理画面プラグイン
などで同様の設計ミスが起きる可能性があります。
そのため、「ユーザーは想定通りに操作する」という前提で設計しないことが非常に重要です。
このような問題は、認証バイパスだけでなく、権限昇格（Privilege Escalation）につながる可能性があります。
よくある疑問
Q. これはログインバイパスですか？
はい。
ログイン処理の途中を壊すことで、管理者権限を取得できるため認証バイパスになります。
Q. なぜ administrator が付与されたのですか？
role-selector が実行されなかったため、デフォルト値として administrator が設定されたためです。
Q. WordPressでも起きますか？
標準のWordPressでは起きません。
しかし、会員サイトや権限管理プラグイン、独自ログインシステムでは同じ問題が起きる可能性があります。
Q. Burp Suiteがないと見つけられませんか？
多くの場合、BurpやZAPなどのプロキシツールを使うことで、リクエスト操作ができるため発見しやすくなります。