2005年 01月 30日
XSSに続く脅威 - HTTP Response Splitting
|
セキュリティホール memo - ■ HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
まだ内容が英語という事もあってしっかり目を通してませんが、
HTTPResponseにリダイレクト投げるパラメータにRequestの入力値を利用するコードで、
CRLFやらなんやらを入力する事によって
複数のResponseをクライアントに返す事が出来てしまう。という物っぽい。
で、主な被害はキャッシュ汚染とのことなんだけど、
Webページのキャッシュの仕組みがよくわからんので、まだ頭の中でつながってないけど、
多分、キャッシュページを攻撃者が自由に作れちゃうので、
元々Responseで帰るページと非常に似て、データ送信先だけ違うページとか埋めると
フィッシングが可能になるよ。ということかな?
対応策はレスポンスに埋めるパラメータからCRLFを除去する事らしい。
ServletAPIで行くと、HttpServletResponse#sendRedirect(String location);の
引数部のStringからCRLFを除去する対策が必要ということかな。
HttpServletResponse#encodeRedirectURL(String url);を通せば勝手にサニタイズされるとうれしいんだけど、
URLエンコードするためのメソッドだし、HttpServletResponseが実装によっちゃう気がするので、
確認が取れるまでは、サニタイズするコードを埋めた方が確実でしょう。
しっかし、よくもまぁこんな事かんがえたねぇ。
ところで、Headerにパラメータを埋められる場合にこの攻撃が成立するならば
入力文字列をSet-Cookieする場合にも当てはまったりするのかな?
試しにコード書いてみたいけど、遊びたいので教えてエロイ人!!
まだ内容が英語という事もあってしっかり目を通してませんが、
HTTPResponseにリダイレクト投げるパラメータにRequestの入力値を利用するコードで、
CRLFやらなんやらを入力する事によって
複数のResponseをクライアントに返す事が出来てしまう。という物っぽい。
で、主な被害はキャッシュ汚染とのことなんだけど、
Webページのキャッシュの仕組みがよくわからんので、まだ頭の中でつながってないけど、
多分、キャッシュページを攻撃者が自由に作れちゃうので、
元々Responseで帰るページと非常に似て、データ送信先だけ違うページとか埋めると
フィッシングが可能になるよ。ということかな?
対応策はレスポンスに埋めるパラメータからCRLFを除去する事らしい。
ServletAPIで行くと、HttpServletResponse#sendRedirect(String location);の
引数部のStringからCRLFを除去する対策が必要ということかな。
HttpServletResponse#encodeRedirectURL(String url);を通せば勝手にサニタイズされるとうれしいんだけど、
URLエンコードするためのメソッドだし、HttpServletResponseが実装によっちゃう気がするので、
確認が取れるまでは、サニタイズするコードを埋めた方が確実でしょう。
しっかし、よくもまぁこんな事かんがえたねぇ。
ところで、Headerにパラメータを埋められる場合にこの攻撃が成立するならば
入力文字列をSet-Cookieする場合にも当てはまったりするのかな?
試しにコード書いてみたいけど、遊びたいので教えてエロイ人!!
by f3c
| 2005-01-30 17:53
| 気になったこと