今回解説するのは、Web Security Academyのラボ「Inconsistent security controls」です。
このラボでは、本来は社員しか使えない管理機能に、一般ユーザーでもアクセスできてしまいます。
しかも攻撃方法はとても単純です。
アカウント登録 → メールアドレス変更だけで、管理者機能に入れてしまいます。
一見すると「そんな単純なミスある？」と思うかもしれません。
しかし、実際のWebサービスでも似たような設計ミスはよく起きています。
この記事では、このラボをWordPressの実例に置き換えながら分かりやすく解説します。
ラボの概要｜社員メールだけ管理機能にアクセスできる仕組み
このラボでは次のような仕組みになっています。
- 管理機能（/admin）は社員だけが使える
- 社員は@dontwannacry.com のメールアドレスを使う
- 社員アカウントだけが管理画面にアクセスできる
一見すると、普通のアクセス制御のように見えます。
しかし実際には、メールアドレス変更時に社員チェックが行われていないため、一般ユーザーでもメールアドレスを変更するだけで社員扱いになってしまいます。
攻撃の流れ｜メールアドレス変更だけで管理権限を取得
攻撃者は次の手順で管理者機能に入ります。
- 一般ユーザーとしてアカウント登録
- ログイン
- メールアドレスを社員ドメインに変更
- 管理画面にアクセス
すると、社員として扱われてしまいます。
【攻撃の流れ】
一般ユーザー登録
↓
アカウント作成
↓
メールアドレスを社員ドメインに変更
↓
社員として認識される
↓
/admin にアクセス可能
このように、メール変更のチェック漏れだけで権限が変わってしまいます。
成立理由｜メールドメインによるアクセス制御の設計ミス
原因はとてもシンプルです。
登録時とメール変更時で、セキュリティチェックが統一されていないことです。
登録時 → メールが@dontwannacry.com か確認
メール変更時 → ドメイン確認をしていない
つまり、
- 登録処理 → 社員チェックあり
- メール変更 → チェックなし
というセキュリティルールの不一致が起きています。
これを、Inconsistent security controls（セキュリティ制御の不一致）と呼びます。
ラボ名「Inconsistent security controls」の意味
「Inconsistent security controls」
意味はそのままで、セキュリティルールが処理ごとにバラバラになっている状態です。
たとえば、
登録 → 社員チェックあり
プロフィール変更 → 社員チェックなし
このようにルールが統一されていないと、想定外の経路から権限を取得できてしまいます。
なぜこれはビジネスロジック脆弱性なのか
ビジネスロジック脆弱性とは、システムの設計ミスを利用する攻撃です。
今回のケースでは、
- SQLインジェクションではない
- XSSでもない
- プログラムのバグでもない
単純に権限の判定ルールが間違っているだけです。
つまり、
設計ミス
↓
権限チェックが不完全
↓
一般ユーザーが管理機能を利用できる
という構造です。
WordPressに置き換えた場合の具体例｜メール変更で社員権限になる会員サイト
では、この問題をWordPressサイトに置き換えてみます。
ユーザー登録
↓
プロフィール編集
↓
メールアドレス変更
↓
管理権限が付与される
例えば、社内専用のWordPressサイトがあるとします。
社員だけがログインできる会員サイトです。
開発者が次のような仕組みを作ったとします。
登録時、
@company.com のメールだけ登録可能
しかしプロフィール編集で、
メールアドレス変更のチェックをしていない
すると、
- 一般ユーザーが別メールで登録
- プロフィール編集
- メールを @company.com に変更
これだけで、社員ユーザーとして扱われてしまいます。
もしこのサイトが
- 管理画面
- 顧客データ
- 商品管理
などを扱うサイトなら、重大な情報漏えいにつながります。
WordPressでの対策ポイント｜メールではなくユーザーロールで権限管理する
この問題を防ぐには、すべての処理で同じ権限チェックを行う必要があります。
特に重要なのは次の3つです。
- 登録時
- メール変更時
- 権限判定時
例えば、
ユーザー権限はメールではなく、role（権限）で管理する
という設計にすることです。
WordPressでは、
administrator
editor
author
subscriber
などのロール管理があるので、メールアドレスだけで権限を決める設計は危険です。
設計視点で見ると何が問題だったのか
今回の問題は
権限チェックが1箇所にしかなかったこと
です。
設計としては
登録
プロフィール変更
ログイン
管理機能
すべてで同じ権限ルールを使う必要があります。
しかし実際には
登録だけチェック
という状態でした。
このような設計は、
あとから機能を追加すると壊れやすいです。
設計視点で整理する（チェックリスト）
実際の診断では以下を見ます。
- プロフィール編集機能があるか？
- メール変更で権限が変わるか？
- ドメインベースのアクセス制御があるか？
- 登録時と更新時の処理に差があるか？
- API経由で更新可能か？
特にWordPressでは、
profile_updateuser_register- REST API
ここは重点チェックポイントです。
設計視点で整理する
チェックリストとして整理すると次の5つです。
- 権限判定はメールアドレスで行っていないか
- 登録時とプロフィール変更で同じチェックをしているか
- ユーザー権限はロール管理になっているか
- 権限変更できる画面は制限されているか
- 管理機能は必ずサーバー側で権限確認しているか
セキュリティ診断時のチェックポイント
セキュリティ診断では、次のポイントを確認します。
- メール変更で権限が変わらないか
- プロフィール編集で権限変更できないか
- 管理機能のアクセス制御があるか
- URL直接アクセスで管理機能が開かないか
特に重要なのは登録以外の経路です。
多くのロジック脆弱性は、
- パスワード変更
- メール変更
- プロフィール編集
などから発生します。
まとめ｜メールアドレスだけで権限を判断してはいけない
今回のラボではセキュリティルールの不一致によって管理機能にアクセスできてしまいました。
原因は
- 登録処理だけチェック
- メール変更でチェックなし
という設計ミスです。
WordPressサイトでも、メールアドレスやユーザー属性などで権限を判定している場合は注意が必要です。
権限管理は必ず統一された仕組みで行うこと。これがロジック脆弱性を防ぐ重要なポイントです。
よくある疑問
Q. メールアドレスで権限管理するのは危険ですか？
基本的に危険です。
メールアドレスはユーザーが変更できるため、権限判定には向きません。
Q. WordPressではこの問題は起きますか？
WordPress本体はロール管理なので安全です。
ただし、カスタム開発や会員サイト機能では起きる可能性があります。
Q. 管理画面のURLを隠せば防げますか？
防げません。
URLが分かればアクセスされるため、サーバー側の権限チェックが必要です。
Q. ビジネスロジック脆弱性は自動スキャンで見つかりますか？
難しいです。
多くの場合、人間が実際に操作して確認する必要があります。