※本記事にはプロモーションが含まれています。
今回は、Web Security Academyの「Authentication bypass via encryption oracle」というラボを解説します。
このラボでは、一見しっかり暗号化されているCookie（クッキー）を悪用して、管理者としてログインできてしまう問題を扱っています。
暗号化されているから安全、という思い込みが崩れる内容で、WordPressでも十分に起こり得る設計ミスです。
ラボの概要│暗号化クッキーが突破される仕組み─ラボの全体像
このラボでは「Stay logged in（ログイン状態を保持）」という機能で発行されるCookieが暗号化されています。
しかし、その暗号を「好きなデータで生成できる」「復号結果を確認できる」という状態になっており、これを悪用すると管理者になりすますことができます。
最終的には、adminとしてログインし、carlosユーザーを削除すればクリアです。
暗号オラクル攻撃の手順─管理者ログインまでの流れ
攻撃のポイントは次の2つです。
- 任意のデータを暗号化できる
- 暗号を復号した結果を画面で確認できる
この2つが揃うことで、暗号の中身を自由に作れるようになります。
【攻撃の流れ】
ログイン状態のCookieを取得
↓
別の機能を使って暗号を復号
↓
Cookieの中身（username:timestamp）を特定
↓
administratorのデータを自作して暗号化
↓
Cookieを書き換えて管理者としてログイン
この流れでは、本来見えないはずの暗号の中身を、エラー表示などを使って少しずつ確認していきます。
なぜ暗号化しても突破されるのか
この問題が起きる理由はシンプルです。
暗号化の仕組みそのものではなく、使い方が間違っているからです。
本来、暗号は次のように使うべきです。
- ユーザーが自由に入力できる値をそのまま暗号処理に使わない
- 復号結果をそのまま画面に出さない
しかしこのラボでは、
- メール入力欄を使って好きな文字列を暗号化できる
- エラーメッセージで復号結果が表示される
という状態になっています。
つまり、暗号ツールをユーザーに貸している状態になっているのです。
ラボ名「encryption oracle」の意味
「encryption oracle（暗号オラクル）」とは、「入力したデータを暗号化してくれる箱」または「暗号データを復号して教えてくれる箱」のことです。
本来は内部でしか使われない機能ですが、それをユーザーが使えてしまう状態を指します。
なぜこれはビジネスロジック脆弱性なのか
この問題は、暗号アルゴリズムのバグではありません。
処理の流れ（ロジック）の問題です。
- コメント投稿機能で暗号化ができる
- エラー表示で復号結果が見える
- ログイン判定がクッキーだけで行われる
この3つが組み合わさった結果、攻撃が成立しています。
つまり、機能同士の組み合わせミスによる脆弱性です。
WordPressで起きる暗号オラクルの例─会員サイトとフォームの危険な組み合わせ
ここでは、このラボの内容を実際のWordPressサイトで起こりそうな形に置き換えて考えてみます。
想定するのは、次のようなサイトです。
- 会員制のWordPressサイト
- ログイン状態を保持する独自機能（またはプラグイン）
- お問い合わせフォーム（Contact Form 7など）
一見すると、どれもよくある構成です。
このサイトでは、ログイン状態を保持するために、次のような情報をCookieに保存していました。
user_id:有効期限ただし、そのままだと改ざんされる可能性があるため、暗号化して保存しています。
ここまでは問題なさそうに見えます。
一方で、お問い合わせフォームでは、入力内容を安全に扱うために、同じ暗号処理を使ってデータを保存していました。
しかし、ここに落とし穴があります。
メールアドレスの入力が間違っていた場合、次のようなエラーが表示されます。
無効なメールアドレス：入力された内容実はこの入力された内容は、一度暗号化されたあとに復号されたデータがそのまま表示されています。
この状態になると、攻撃者は次のことができてしまいます。
- 好きな文字列を暗号化できる
- 暗号化されたデータを復号して確認できる
つまり、暗号を自由に扱える状態になっています。
【WordPressでの再現フロー】
フォームに任意の文字列を入力
↓
その内容が暗号化される
↓
エラー画面で復号された内容が表示される
↓
クッキーの中身（user_id:期限）を特定できる
↓
administratorのデータを作成して暗号化
↓
クッキーを書き換えて管理者としてログイン
この流れでは、本来は見えないはずのCookieの中身が、フォーム機能を通じて明らかになってしまいます。
ここで重要なのは、1つ1つの機能はすべて正しいことをしている点です。
- Cookieを暗号化している
- 入力データを安全に処理している
- エラーメッセージを表示している
しかし、これらを同じ暗号処理でつないでしまったことが問題です。
WordPressでは、プラグインやカスタムコードを組み合わせて機能を作ることが多いため、
- ログイン機能
- フォーム機能
- エラー表示
のような別の機能が思わぬ形でつながることがあります。
その結果、本来は安全なはずの暗号処理が、攻撃者にとって便利なツールになってしまうのです。
このように、WordPressでは機能単体では安全でも、組み合わせによって危険になるというケースが現実的に起こり得ます。
特に、独自ログインや会員サイトを構築している場合は、同じような問題が起きていないか注意が必要です。
WordPressでの対策ポイント
重要なのは次の考え方です。
- ユーザー入力を暗号処理に直接使わない
- 復号結果を画面に出さない
- Cookieだけで認証しない
特にWordPressでは、
- 独自ログイン機能の実装
- 会員サイトプラグインのカスタマイズ
- WooCommerceのセッション管理
などで同様のミスが起きやすいです。
設計視点で見ると何が問題だったのか
問題の本質は機能の分離ができていないことです。
本来は、
- 暗号処理は内部だけで使う
- エラー表示は安全な情報だけ出す
と分けるべきでした。
しかしこのラボでは、
- 暗号機能
- 表示機能
- 認証機能
がすべてつながってしまっています。
設計視点で整理する
チェックポイントとしては次の通りです。
- ユーザー入力がそのまま暗号処理に使われていないか
- 復号結果を画面に表示していないか
- クッキーの中身を信用しすぎていないか
- 別機能から認証情報を推測できないか
- エラーメッセージに情報が出すぎていないか
脆弱性診断で見るべきポイント─暗号オラクルの見つけ方
実際にサイトをチェックするときは、次の視点が重要です。
- エラー文に入力値がそのまま出ていないか
- Cookieの値を変えると挙動が変わるか
- ログイン状態がサーバーではなくCookieだけで管理されていないか
こういったポイントを見ると、同じタイプの問題を見つけやすくなります。
まとめ─暗号化しても安心できない理由
今回のポイントは「暗号＝安全ではない」という点です。
- 暗号そのものは安全でも
- 使い方を間違えると意味がない
特にWordPressでは、プラグインや独自機能の組み合わせで同じ問題が起きやすいです。
機能単体ではなく、全体の流れで安全性を考えることが重要です。
よくある疑問
Q. 暗号化していれば安全ではないのですか？
いいえ。
使い方が間違っていると、今回のように中身を操作されます。
Q. WordPress標準機能では大丈夫ですか？
基本的には安全ですが、独自実装やプラグインの組み合わせで問題が起きることがあります。
Q. エラーメッセージはどこまで出していいですか？
ユーザー入力や内部データは出さないのが基本です。
Q. Cookieだけでログイン管理してもいいですか？
危険です。
サーバー側でも必ずチェックが必要です。