Hello there, ('ω')ノ
🎯 ラボの目的
このラボでは、HTTPリクエストのHostヘッダーを悪用して認証を回避する方法を学びます。 特定のHost値（例：localhost）で接続した場合にのみ管理機能が有効になるという設計を突き、 管理画面への不正アクセスと、ユーザー削除（carlos）を達成するのが目的です。
🧩 攻略手順（ステップバイステップ）
✅ 1. 通常アクセスの動作確認
/にアクセスして200 OKが返ることを確認。- このリクエストをBurp SuiteのRepeaterに送る。
✅ 2. Hostヘッダーの任意値テスト
- Repeater上で
Host: anything.comのように変更して送信。 - 正常にページが表示されれば、Hostの値が無視されている（脆弱性の兆候）。
✅ 3. /robots.txt を確認
Disallow: /adminが記載されていれば、管理画面のパスは/admin。
✅ 4. /admin にアクセス
- ブラウザでアクセスすると、「内部ユーザーのみがアクセス可能」などのエラーメッセージが出る。
✅ 5. Hostを localhost に変更して再アクセス
- Repeaterで
/adminへのリクエストにHost: localhostを追加。 - 成功すれば、管理画面にアクセス可能。
- 画面上に「ユーザー削除」などのオプションが表示される。
✅ 6. ユーザー削除を実行
- リクエストラインを以下に変更：
GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
- リクエストを送信して
carlosを削除。 - 成功すればラボ完了。
🔍 技術的解説
- サーバ側で「Host: localhost」での接続を信頼された内部接続と誤認識している。
- 通常のユーザーは「example.com」などでアクセスするため、Hostを偽装することで内部扱いに昇格可能。
- HostヘッダーはHTTP/1.1以降必須項目だが、身元認証として使うのは設計ミス。
⚠ 教訓と対策
| 問題点 | 対策例 |
|---|---|
| Hostヘッダーによる信頼判断 | IPベースのファイアウォール制御やVPNの使用 |
| 管理画面への簡易アクセス制御 | 強制ログイン／認証プロセスを導入 |
| 内部と外部の区別を論理で制御 | ホスト名ではなくセッション／認証トークンで判断する設計に |
Best regards, (^^ゞ
