Hello there, ('ω')ノ
HTTPヘッダーインジェクションとは？
システム側が受け取ったデータをそのままHTTPヘッダーに反映している場合：
- 不正な値を送り込むことで
- 本来意図しない挙動が発生してしまう
そんな状態をHTTPヘッダーインジェクションと呼びます。
主なリスク：
- リダイレクト先の改ざん
- Cookieの不正設定
- レスポンスヘッダー書き換え
代表的な発生例
このurl= の値に以下のような文字を入れると：
%0d%0aSet-Cookie:%20session=evil
→ 攻撃者が自分でCookieを設定できてしまう場合があります。
- Locationヘッダー操作：
ユーザー入力値がそのままLocationヘッダーに使われているケース。
実際のチェック手順① リダイレクト用URLを探す
- ログイン後のリダイレクト機能
- ログアウト後のリダイレクト機能
- エラー発生時のリダイレクト
こういったURLを開発者ツールのNetworkタブで探します。
実際のチェック手順② 改ざん用文字列を追加
よく使われる改ざん例：
- %0d%0aSet-Cookie:%20test=1
- %0d%0aContent-Type:%20text/html
例：
https://intra.example.co.jp/redirect?url=https://example.com%0d%0aSet-Cookie:%20test=1
実際のチェック手順③ 結果を確認
- 開発者ツール → Networkタブ
- 該当リクエストのレスポンスヘッダーを確認
✅ 観察ポイント：
- 本来ないはずのヘッダーが追加されていないか？
- Cookieが増えていないか？
- リダイレクト先が変わっていないか？
よくあるチェック対象
- ログイン・ログアウトページ
- ファイルダウンロード機能
- URLパラメーターを利用している機能
チェックリストまとめ
- [ ] リダイレクトやLocationヘッダーを利用しているURLを洗い出したか？
- [ ] %0d%0a を含む改ざんパラメーターでテストしたか？
- [ ] Networkタブでレスポンスヘッダーを確認したか？
- [ ] 本番環境で試す前に必ず許可を取ったか？
注意事項
- 本番環境でのチェックは慎重に
- 実施後はシステム担当者や情報セキュリティ部門へ報告
まとめ
- HTTPヘッダーインジェクションは「見えない場所」で起こる脆弱性
- URLパラメーター＋改ざん文字列＋レスポンスヘッダー確認が基本流れ
- 非エンジニアでも手順通り進めれば十分チェック可能
Best regards, (^^ゞ
