応答ヘッダやメールヘッダに利用者の入力を埋め込むと何が起きるのかを、改行の扱いから解説。オープンリダイレクトとの組み合わせ、根本対策としての専用 API の利用、情報処理安全確保支援士試験での問われ方まで。
ヘッダインジェクションは、応答ヘッダやメールヘッダを組み立てるときに、利用者から受け取った文字列をそのまま埋め込むことで成立します。鍵になるのは改行です。ヘッダとヘッダの区切りが改行である以上、改行を通してしまえば、こちらの意図しないヘッダを足されます。SQL インジェクションやトラバーサルと同じで、「解釈される場所へ無検査で渡した」という構図です。
典型的な入口は、リダイレクト先やクッキーの値を、要求のパラメータから組み立てている箇所です。埋め込まれた値に改行が含まれていると、応答の構造が崩れます。新たなヘッダを足されたり、ヘッダの終わりを偽装して本文を差し込まれたりします。結果として、意図しないクッキーを設定される、キャッシュに偽の応答を残される、といった影響が出ます。
# 【危険】受け取った値を、そのままヘッダに組み立てている
response.headers["Location"] = "/go?to=" + param
# 【安全】専用の API に渡し、値として扱わせる
return redirect(url_for("page", name=param))
根本対策は、ヘッダを自分で文字列として組み立てないことです。フレームワークが用意しているリダイレクトやクッキー設定の仕組みを使えば、値は値として扱われ、改行が構造に影響しません。やむを得ず自前で組み立てる場合は、改行を含む入力を受け付けない（除去ではなく拒否する）ようにします。
遷移先を利用者の入力から決めている機能は、それ自体が問題になります。正規のドメインで始まる URL から、攻撃者のサイトへ飛ばせるからです。利用者は URL の先頭を見て安心してしまうため、偽サイトへの誘導が成功しやすくなります。ヘッダインジェクションと組み合わされることが多く、同じ箇所を直すことになります。
問い合わせフォームから送信するメールでも、同じことが起きます。件名や差出人にあたる欄に改行を含む値を入れられると、宛先のヘッダを足されます。受け取る側からは見えない宛先を追加されれば、気づかないまま第三者へ送られ、迷惑メールの踏み台にされます。自組織のドメインが受信拒否の対象になる、という二次被害にも繋がります。
対策の考え方は HTTP のときと同じです。ヘッダを自前で組み立てず、メール送信のライブラリに宛先・件名・本文を分けて渡します。加えて、フォームから指定できる宛先は固定にしておき、利用者の入力から決めないようにします。
改行を除去する対策は、他のインジェクションと同じ理由で不十分になりがちです。エンコードされた表記や、複数の表現が残るためです。除去して安全にするのではなく、そもそも構造に影響しない渡し方をする——これが根本対策と呼ばれる理由です。入力の検証は、想定外の値を早めに弾くための補助として位置づけます。
応答の構造を崩されたとき、影響がその要求だけで終わらないことがあります。途中にキャッシュを置く構成では、偽装された応答がキャッシュに保存され、その後に同じ URL を要求した別の利用者へ配られてしまいます。一人を狙った操作が、多数の利用者へ広がる形です。CDN やリバースプロキシを挟んでいる場合は、この点まで含めて影響を評価します。
クッキーを追加されるのも軽い被害ではありません。セッションに関わる値を差し込まれれば、利用者が意図しない状態でサービスを使わされます。ヘッダは応答の骨組みなので、そこに手を入れられるということは、その後のすべてのやり取りの前提が崩れるということです。入力の一箇所の不備が、広い範囲に効いてしまいます。
午前Ⅱでは、攻撃に使われる文字（改行）と、脆弱性の名称の識別が問われます。午後では、リダイレクト処理や問い合わせフォームの実装を示して「何が起きるか」「対策」を書かせる形です。令和4年度 春期の午後Ⅰでも、空欄補充の形でこの論点が扱われました。対策を書くときは「改行を除去する」ではなく「ヘッダを自前で組み立てず、専用の API に渡す」まで書けると強くなります。
IPA 公式 PDF：令和4年度 春期 午後Ⅰ問題 ↗本文はこの公式 PDF でご覧ください（アプリ内には転載していません）。