HTTPレスポンス分割の例

HTTPレスポンス分割に利用されることが多いのは、HTTPヘッダーのフィールドのうちリダイレクト先を指定するLocation:フィールドやCookieを設定するSet-Cookie:フィールドです。
例えば、ユーザが選択した言語をリクエスト パラメータに含めて送信し、それに従って各言語別のページにリダイレクトするアプリケーションがあるとします。
　
正常なレスポンス ヘッダーは次のようになります。


ここで、Japaneseの代わりに次の内容をパラメータとして送信します。


すると次のようなレスポンスが生成されます。


HTTPの仕様では、ヘッダーの終了は改行コード(CR+LF、URLエンコードされた形式では%0d%0a)2つによって表されます。従って、上の例の｢Content-Length: 0｣の後で1つのレスポンスが終了し、｢HTTP/1.1 200 OK｣以降は別のレスポンスを構成すると解釈されます。2番目のレスポンスの内容は、完全に攻撃者の制御下にあります。 攻撃者は、この偽のレスポンスをプロキシ サーバにキャッシュさせるなどの方法で、他のユーザも偽のレスポンスを取得するようにします。これによってページの偽装、クロスサイト スクリプティング、Cookieの操作などの攻撃が可能になります。

対策

HTTPレスポンス分割を防ぐには、ユーザからの入力データの検証と、出力データの適切なエンコーディングを徹底します。
入力データをヘッダーに出力する前に、改行コード(CR+LF)が含まれていないかをチェックします。アプリケーションでLocationフィールドに値を設定する場合、改行コードを取り除きます。Set-Cookieフィールドに値を設定する場合は、必ずURLエンコードします。

dotTESTのルール

○ HTTP レスポンス分割から防御する
このルールは、改行を含んでいる可能性のある入力データが、検証メソッドによるチェックを受けないまま出力メソッドに渡されている場合に違反をレポートします。このルールはフロー解析ルールなので、入力データの取得と出力が別のメソッドに分かれていたり、複数の実行パスが存在する場合でも、実行パスを辿って違反を検出することができます。ルールのパラメータをカスタマイズすることによって、どの入力データをチェック対象にするかを指定することができます。

dotTESTのHTTP レスポンス分割から防御するルールでソースコードを解析することにより、HTTPレスポンス分割による攻撃に対して脆弱なコードを発見し、改修することが可能になります。

※ セキュリティルール及びセキュリティコンプライアンス規約セットによる静的解析には「セキュリティコンプライアンスパック」のライセンス(有償)が必要です。