Jtest Security－Java対応ソースコードセキュリティ検証ツール－

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レスポンス分割から防御する

このルールは、改行を含んでいる可能性のある入力データが、検証メソッドによるチェックを受けないまま出力メソッドに渡されている場合に違反をレポートします。このルールはバグ探偵(フロー解析)ルールなので、入力データの取得と出力が別のメソッドに分かれていたり、複数の実行パスが存在する場合でも、実行パスを辿って違反を検出することができます。
　

チェックできる入力データ

• リモート メソッドおよびエントリ ポイント メソッドのパラメータ
• ネイティブ メソッド
• 検証を行っていない Struts フォーム
• ネットワーク
• Servlet リクエスト
• ファイル
• パイプ
• リモート メソッド
• リフレクション メソッド
• 環境変数およびシステム プロパティ
• データベース
• ストリーム指向 API (ストリーム、リーダー、チャネル)
• コンソール
• GUI コントロール

チェックできる出力メソッド

• javax.servlet.http.HttpServletResponse
  • void sendRedirect(...)
  • void addCookie(...)
  • void addIntHeader(...)
  • void addDateHeader(...)
  • void setHeader(...)
  • void setIntHeader(...)
  • void setDateHeader(...)
  • void setStatus(...)

• javax.faces.context.ExternalContext
• void redirect(...)

また、ルールのパラメータをカスタマイズすることによって、どの入力データおよび出力メソッドをチェック対象にするかを指定することができます。

　

検証メソッドの指定も可能

ルールのパラメータでは検証メソッドを指定することも可能です。検証メソッドは、改行を含んでいる可能性のある入力データを受け取り、チェック済みの安全なデータをパラメータまたは戻り値として返すメソッドです。検証メソッドをパラメータで指定しておくと、チェック済みのデータに対して誤って違反が検出されることがなくなるため、検証結果の精度が向上します。

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