Hello there, ('ω')ノ
1. 攻撃チェーン全体像
ステップ1: キャッシュポイズニング
- 目的: Webキャッシュサーバ（CDNやリバースプロキシ）に 攻撃者が細工したレスポンスを保存させる。
ステップ2: Stored XSS
- 目的: キャッシュされたレスポンスの中に 悪意のあるスクリプトを含めることで、 不特定多数のユーザにXSSを仕掛ける。
2. 実際の流れと具体的テクニック
① 脆弱なキャッシュ条件を探す
調査項目:
- Hostヘッダー がキャッシュキーに含まれているか
- X-Forwarded-Host などのヘッダーが影響しているか
- クエリパラメータ の有無によるキャッシュ動作確認
具体例:
Host: victim.com X-Forwarded-Host: attacker.com
観察ポイント:
- リダイレクトURLやレスポンス本文にヘッダーの値が反映されるか
- 異なるヘッダー値でキャッシュが分離されないか
② キャッシュポイズニング実行
細工したリクエストを送る
例:
GET /somepage HTTP/1.1 Host: victim.com X-Forwarded-Host: attacker.com
そのリクエスト結果が他のユーザに返ることを確認
- キャッシュサーバのレスポンスを見る
- Cache-Control ヘッダーなども観察
③ Stored XSSへの展開
条件:
- キャッシュされたレスポンス内に HTMLやJavaScriptコードがそのまま挿入される場所があること
例:
- ログインページのリダイレクト先
- エラーページのメッセージ内容
実際の攻撃手順:
- X-Forwarded-Host などに以下のような値を入れる:
"><script>alert(1)</script>
- それを含んだレスポンスがキャッシュされると すべてのユーザに対してStored XSSが成立
3. 攻撃成立条件まとめ
- キャッシュ分離ミス → HostヘッダーやX-Forwarded-Hostがキャッシュキーに含まれない
- レスポンスリフレクション → 攻撃者入力がレスポンスにそのまま含まれる
- キャッシュ可能設定 → Cache-Control: public など
4. 実務での確認ポイントチェックリスト
✅ キャッシュポイズニング関連
- [ ] Host ヘッダーがキャッシュキーに含まれているか確認
- [ ] X-Forwarded-Host や X-Forwarded-For が影響するか確認
- [ ] クエリパラメータ付きURLのキャッシュ動作確認
- [ ] Cache-Control ヘッダーの内容チェック
- [ ] エラーページやリダイレクトページのキャッシュ確認
✅ XSS関連
- [ ] レスポンス内に動的に生成されるHTMLやJSが含まれるか
- [ ] X-Forwarded-Host や Referer がHTMLに埋め込まれていないか確認
- [ ] HTMLエスケープやContent-Security-Policy (CSP)が設定されているか確認
✅ 総合
- [ ] キャッシュ＋XSS成立までを一通り手順化
- [ ] 複数回再現できるか検証
- [ ] 自社サービスや運用中システムで同様の条件がないか確認
おわりに
キャッシュポイズニング単体やStored XSS単体は知られていても、 両者を組み合わせた攻撃チェーンは見逃されがちです。
このガイドをベースに、実際のペネトレーションテストや脆弱性診断業務で 応用・チェックを行うことをおすすめします。
Best regards, (^^ゞ
