安全なウェブサイトの作り方 - 1.7 HTTPヘッダ・インジェクション

概要

ウェブアプリケーションの中には、リクエストに対して出力するHTTPレスポンスヘッダのフィールド値を、外部から渡されるパラメータの値等を利用して動的に生成するものがあります。たとえば、HTTPリダイレクションの実装として、パラメータから取得したジャンプ先のURL情報を、Locationヘッダのフィールド値に使用する場合や、掲示板等において入力された名前等をSet-Cookieヘッダのフィールド値に使用する場合等が挙げられます。このようなウェブアプリケーションで、HTTPレスポンスヘッダの出力処理に問題がある場合、攻撃者は、レスポンス内容に任意のヘッダフィールドを追加したり、任意のボディを作成したり、複数のレスポンスを作り出すような攻撃を仕掛ける場合があります。このような問題を「HTTPヘッダ・インジェクションの脆弱性」と呼び、この問題を悪用した攻撃手法は「HTTPヘッダ・インジェクション攻撃」と呼びます。特に、複数のレスポンスを作り出す攻撃は、「HTTPレスポンス分割（HTTP Response Splitting）攻撃」と呼びます。

発生しうる脅威

本脆弱性を突いた攻撃により、発生しうる脅威は次のとおりです。

クロスサイト・スクリプティング攻撃により発生しうる脅威と同じ脅威: 任意のレスポンスボディを注入された場合、利用者のブラウザ上で偽の情報を表示させられたり、任意のスクリプトを埋め込まれたりする可能性があります。これは、前述「1.5 クロスサイト・スクリプティング」で解説した「発生しうる脅威」と同じ脅威です。

任意のCookie発行: Set-Cookie ヘッダを注入された場合、任意のCookie が発行され、利用者のブラウザに保存される可能性があります。

キャッシュサーバのキャッシュ汚染: 複数のレスポンスに分割し、任意のレスポンスボディをリバースプロキシ等にキャッシュさせることにより、キャッシュ汚染（ウェブページの差し替え）を引き起こし、ウェブページの改ざんと同じ脅威が生じます。この攻撃を受けたウェブサイトにアクセスする利用者は、この差し替えられた偽のウェブページを参照し続けることになります。クロスサイト・スクリプティング攻撃のように、攻撃を受けた直後の本人のみが影響を受ける場合に比べ、キャッシュ汚染による脅威は、影響を受ける対象が広く、また永続的であることが特徴です。

注意が必要なウェブサイトの特徴

運営主体やウェブサイトの性質を問わず、HTTP レスポンスヘッダのフィールド値（Locationヘッダ、Set-Cookieヘッダ等）を、外部から渡されるパラメータの値から動的に生成する実装のウェブアプリケーションに注意が必要な問題です。Cookieを利用してログインのセッション管理を行っているサイトや、サイト内にリバースプロキシとしてキャッシュサーバを構築しているサイトは、特に注意が必要です。

届出状況

HTTPヘッダ・インジェクションの脆弱性の届出がウェブサイトの届出全体に占める割合は数パーセントと多くはありません。しかしながらこれらの脆弱性については受付開始当初から継続的に届出を受けています。下記は、IPAが届出を受け、同脆弱性の対策が施されたソフトウェア製品の例です。

根本的解決

7-(i)-a ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用する。

ウェブアプリケーションの実行環境によっては、Content-TypeフィールドをはじめとするHTTPレスポンスヘッダを、プログラムで直接出力するものがあります。このような場合に、フィールド値に式の値をそのまま出力すると、外部から与えられた改行コードが余分な改行として差し込まれることになります。HTTPヘッダは改行によって区切られる構造となっているため、これを許すと、任意のヘッダフィールドや任意のボディを注入されたり、レスポンスを分割されたりする原因となります。ヘッダの構造は継続行が許される等単純なものではありませんので、実行環境に用意されたヘッダ出力用のAPIを使用することをお勧めします。

ただし、実行環境によっては、ヘッダ出力APIが改行コードを適切に処理しない脆弱性が指摘されているものもあります。その場合には修正パッチを適用するか、適用できない場合には、次の 7-(i)-b または 7-(ii) の対策をとります。

7-(i)-b 改行コードを適切に処理するヘッダ出力用APIを利用できない場合は、改行を許可しないよう、開発者自身で適切な処理を実装する。

例えば、改行の後に空白を入れることで継続行として処理する方法や、改行コード以降の文字を削除する方法（脚注1）、改行が含まれていたらウェブページ生成の処理を中止する方法等が考えられます。

保険的対策

7-(ii) 外部からの入力の全てについて、改行コードを削除する。

外部からの入力の全てについて、改行コードを削除します。あるいは、改行コードだけでなく、制御コード全てを削除してもよいかもしれません。ただし、ウェブアプリケーションが、TEXTAREAの入力データ等、改行コードを含みうる文字列を受け付ける必要がある場合には、この対策のように一律に全ての入力に対して処理を行うと、対策を実施したウェブアプリケーションが正しく動作しなくなるため、注意が必要です。

以上の対策により、HTTPヘッダ・インジェクション攻撃に対する安全性の向上が期待できます。HTTPヘッダ・インジェクションの脆弱性に関する情報については、次の資料も参考にしてください。