OWASP AppSec APAC 2014で発表しました

OWASP AppSec APAC 2014 で、はせがわようすけさん、malaさんと一緒に、「XSS Allstars from Japan」という枠で登壇しました。3人それぞれ好きなテーマについて発表をしたのですが、僕は、2011年頃から個人的にやってきた、文字エンコーディングの調査について発表しました。

スライドは以下で公開されています。

The Complete Investigation of Encoding and Security // Speaker Deck

はせがわさんのスライドはこちら： Bypass SOP, Theft your data // Speaker Deck
malaさんのスライドはこちら： XSS with HTML parsing confusion // Speaker Deck

エンコーディングに関する様々な調査結果は以下で公開しています。

http://l0.cm/encodings/


結果に変更があり次第、更新していきます。最近もFirefox 28で大きな変更があったので既に反映させました。(@vyv03354さん、お知らせ頂きありがとうございます)
もともと誰かにみせることを前提に調査していなかったので、荒い部分もあるかもしれません。おかしなところがあれば教えてください。

以下、発表では伝えきれなかったこと、確実に伝えたいことを Q & A 形式でお送りします。


Q.
CVEがついてるものとそうでないものが混じってるけど、公開しても大丈夫なの？
A.
掲載されているものすべてが脆弱性と言えるものとは限りません。脆弱性とみなされるような問題は修正されています。
  

Q.
わたしは開発者です。手っ取り早く、すべきことはなに？
A.
charsetを"レスポンスヘッダで"確実に指定してください。

Q.
なぜ、"レスポンスヘッダで"すべきなの？
A.
レスポンスヘッダによる指定の方が、誤って別のエンコーディングで解釈される可能性が低くなるからです。一例をあげると、<meta http-equiv>でのみcharset指定をしていた場合、IEのXSSフィルターは、URLに「<meta http-equiv=>」といった文字を与えるとcharset指定を破壊できてしまうので、ページのcharsetが不明瞭( =ブラウザが自動で選択する )になってしまいますが、レスポンスヘッダによる指定はこの影響を受けません。

Q.
普段誰も使っていないエンコーディングを調べて意味あるの？
A.
UTF-7はほとんど使われていませんが、攻撃に利用できるとして問題になったように、危険性を考える上で、普段使われていないエンコーディングの挙動を調べることにも価値があるはずです。




その他、疑問点などありましたら言って頂ければお答えします。


OWASP AppSec APAC 2014に関わった皆様、お疲れ様でした。
スタッフの方々、撮影の不可など、ご配慮いただきましてありがとうございました。
一緒に発表したはせがわさん・malaさん、発表には不慣れですが、頼りになる2人と一緒だったので心強かったです。ありがとうございました。
同時通訳の方、しゃべるの早すぎるし、言葉が滑らかにでてこないしで、 相当大変だったと思います。発表中は通訳さんのことを考えている余裕がありませんでした…。大変ご迷惑をおかけしました。ありがとうございました。
最後に、拙い発表を聴いて下さったたくさんの方々、ありがとうございました。

このような素晴らしいイベントに関われて本当に嬉しいです。

------
2014年4月2日更新： スライドのリンクが変更されていたので修正しました。