HTTPヘッダインジェクション【HTTP Header Injection】とは｜図でわかる脆弱性の仕組み

概要

HTTPヘッダインジェクションとは、ユーザ⼊⼒値などのクライアントから送信される値を適切に処理することなく、HTTPレスポンスヘッダに含めてしまうことにより発⽣する脆弱性および攻撃⼿法です。

この脆弱性を使⽤して、攻撃者はHTTPレスポンスヘッダに任意のヘッダフィールドを追加したり、レスポンスボディに任意のコンテンツを追加できるため、さまざまな攻撃の⽷⼝となる危険性があります。

その結果、正規ユーザのアカウントの乗っ取りやなりすまし、サイト利⽤者に表⽰されるコンテンツの改ざん、外部サイトへの意図しないリダイレクトなどにつながります。

関連ゼイジャッキー

HTTPヘッダについて

初めに、HTTPヘッダインジェクションを説明する前に、HTTPヘッダについて簡単に説明します。
HTTPヘッダとは、HTTPリクエストおよびHTTPレスポンスを構成する要素の1つです。HTTPヘッダには、クライアントとサーバが通信する際の詳細な説明や制御情報などが格納されています。

HTTPヘッダは、1⾏ごとに1つの情報を持ち、それらは改⾏⽂字(CR(\r)およびLF(\n))によって区切られます。
また、HTTPヘッダとHTTPメッセージボディは改⾏⽂字で終わる空⽩⾏によって区切られます。

以降上記の仕様を踏まえて、本脆弱性について解説します。

脆弱性の仕組み

HTTPヘッダインジェクションは、ユーザ⼊⼒値に含まれる改⾏⽂字を、適切に処理しないことによって発⽣します。

ここでは、HTTPヘッダインジェクションの脆弱性がある場合、改⾏⽂字がどのように作⽤するのかを踏まえて、攻撃が成⽴する仕組みについて解説します。

レスポンスヘッダが改ざんされる仕組み

冒頭で解説したとおり、HTTPヘッダフィールドの各ヘッダは改⾏⽂字によって区切られます。

ここでは、例としてリダイレクト処理において、パラメータによってリダイレクト先のURLを受け取り、レスポンスのLocationヘッダに出⼒するような実装のあるアプリケーションを考えます。
レスポンスヘッダにユーザ⼊⼒値を含める処理を実装している場合、攻撃者はパラメータなどの⼊⼒値に改⾏⽂字を含めることで、任意のヘッダフィールドを追加しようとします。
本来ヘッダ値として出⼒する値は改⾏⽂字で分割され、結果としてサーバからのHTTPレスポンスには、改⾏⽂字以降が独⽴したヘッダとして配信されます。

以下の図において、%0d%0aは改⾏⽂字(\r\n)をURLエンコードした値を⽰しています。

レスポンスボディが改ざんされる仕組み

またHTTPヘッダとボディは改⾏⽂字を含む空⽩⾏によって区切られます。
攻撃者は、⼊⼒値に連続した改⾏⽂字を含めることで、レスポンスボディに任意のコンテンツを追加できます。

以下は、パラメータで受け取った値を、レスポンスのSet-Cookieヘッダにそのまま反映する実装がある場合の例です。

攻撃例

ここでは、いくつかの攻撃例について解説します。

HTTPヘッダインジェクションの脆弱性があるアプリケーションにおいて、たとえば以下のような攻撃ケースが想定されます。

• Set-Cookieヘッダを追加し、正規ユーザが利⽤するCookieに任意の値を設定する
• レスポンスボディを任意のコンテンツに改ざんする

ここでは、これらの攻撃ケースについて図を踏まえて解説します。

また、正規の同名ヘッダが既に存在し、攻撃者によって挿入された悪意あるヘッダの上に配置される場合、サーバの実装や仕様によっては動作しない可能性があります。

Set-Cookieヘッダを追加し、正規ユーザが利⽤するCookieに任意の値を設定する

⼤まかには、次のような流れでHTTPヘッダインジェクションから、セッションの固定化につなげることができます。

1. 攻撃者はHTTPヘッダインジェクションを⽤いて、Set-Cookieヘッダに任意のセッションIDを指定するように細⼯したURLを何らかの⽅法で正規ユーザにクリックさせる
2. 正規ユーザは細⼯されたURLから脆弱なサイトにアクセスする
3. 攻撃者は指定したセッションIDを⽤いて、正規ユーザとしてサイトにアクセスする

これにより、ユーザに任意のCookieを強制できることから、セッションの固定化（Session Fixation）攻撃につながる可能性があります。セッションの固定化攻撃は、正規ユーザに攻撃者が⽤意したセッションIDの使⽤を強制する攻撃⼿法です。

セッションの固定化については、過去の記事で詳しく解説しているため、そちらを参照してください。

詳細はこちら

レスポンスボディを任意のコンテンツに改ざんする

攻撃者は、次のようなシナリオで、ユーザが受け取るコンテンツを任意のコンテンツに改ざんします。

1. 攻撃者は、細⼯されたURLを正規ユーザにクリックさせる
2. 正規ユーザは、細⼯されたURLから脆弱なWebサイトにアクセスする
3. 正規ユーザは、攻撃者の指定したコンテンツを含んだレスポンスを受け取る

レスポンスボディを任意のコンテンツに改ざん可能であることから、たとえば任意のコンテンツに悪意あるスクリプトを含めることで、クロスサイトスクリプティング（XSS）につなげることも可能です。

XSSについては、過去の記事で詳しく解説しているので、そちらを参照してください。

詳細はこちら

JVN iPediaに登録された本脆弱性の件数

HTTPヘッダインジェクションは、CRLFインジェクションと呼ばれる改⾏⽂字を適切に処理しないことに起因した脆弱性の⼀種であると考えられます。

以下の表およびグラフは、CRLFインジェクションの脆弱性（CWE-93）が存在するとしてJVNに登録された、直近10年間での件数です。

件数としてやや少なく⾒えますが、HTTPヘッダインジェクションは脆弱性の性質上、他の脆弱性を⽤いた攻撃の踏み台とされることも少なくありません。たとえば、本記事であつかったHTTPヘッダインジェクションはCWE-113（HTTPレスポンス分割）として報告されることもありますし、また別の脆弱性として報告されることもあります。

対策

ユーザ⼊⼒値をレスポンスヘッダに含めないでください。
ただし、実装要件としてユーザ⼊⼒値をレスポンスヘッダに含める必要がある場合は、改⾏⽂字を出⼒しないでください。

なお、モダンなWebアプリケーションフレームワークでは、本脆弱性が対策されているケースが多くなっているため、フレームワークの利⽤を推奨します。たとえば、PHP 5.4.1以降のheader()関数は、改⾏⽂字を使⽤した複数⾏のヘッダを送信できないように対策されています。

多くのプログラミング⾔語やフレームワークは、ヘッダを適切に出⼒する関数を備えています。それらがバリデーションを適切に⾏っていることを確認したうえで、必要に応じてバリデーション処理を実装してください。

まとめ

HTTPヘッダインジェクションの脆弱性が存在していると、セッションの固定化やクロスサイトスクリプティングといった、他の攻撃への⽷⼝として利⽤されます。

その結果、正規ユーザのアカウントの乗っ取りやなりすまし、サイト利⽤者に表⽰されるコンテンツの改ざん、外部サイトへの意図しないリダイレクトによるフィッシング被害などが発⽣します。

こうした被害を防ぐためにも、ユーザが制御可能な値をそのまま使⽤することは避けるほか、本当にそのような実装が必要であるか、再検討してください。