κeenのHappy Hacκing Blog | Lispエイリアンの狂想曲

Shibuya.XSS TT #5 に参加してきました

強化練中のκeenです。明日も朝早いのでこんな時間にエントリー書いてて寝坊しないか心配です。

Shibuya.XSS TT #5 がLINEのオフィスで行なわれてたので覗きに行ってきました。名前はXSSですが内容はセキュリティ全般でしたね。 Mozillaの脆弱性バグ報奨金制度にチャレンジした話だとか色々あったのですがやっぱセキュリティの話なのでオフレコな話題が多く、あまり書けることは無いです。 malaさんが飛び入りでさっきサイボウズの脆弱性を見付けたから話します、ってやろうとしてサイボウズの竹迫さんに止められてたり(結局Googleの未修正の脆弱性の話してました。データガンガン抜いててやばかった。)。

話せる話題はblob URI SchemeとサニタイズとmXSSの話ですね。(俄知識なので誤謬があるかと思います。あまり信用しないで下さい)

blob URI Scheme

example.com/XXXXXX-XXXXXX-XXXXXX みたいなURLのことです。blobの名前の通りバイナリをデコードしたURLで、アップロードした画像の一時URLなんかに使われるそうです。似たようなのにdata URI Schemeとかjavascript URI Schemeとかがあるそうです。

これの扱われ方が他とはちょっと違うらしく、iframe内でこのURIでXSSをするとoriginが親コンテンツのものになるそうです。つまりiframe内からSame Origin Policy突破可能。その他にも面白い特徴があって要研究って言ってました。

サニタイズとmXSS

mutate base XSSだったかな?

ユーザーの入力をJS側でサニタイズしようとする時の話です。 一つ思い付くのはJSでHTMLパーザを書いて許可しないタグを検出する方法ですが、どうしてもブラウザのパーザと互換性を確保出来ない(ブラウザ毎の非互換性がある)ためそこが脆弱性になるそうです。

そこでブラウザのパーザを呼び出すAPIがあるのでそれを使ってDOMを作り、タグを洗い出す方法が考えられます。ここまでは良いのですが、最後HTMLに追加するときに文字列化してinnerHTMLで書き込もうとするとmXSSの危険性があるそうです。具体的には特定の状況で&lt;&gt;<>に変化してしまい、入力と出力でDOM構造が変わってしまうことがあるそうです。怖い。

セキュリティ大変ですね。

Written by κeen