IEのinnerHTMLにおけるバッククォートバグ問題について(その2)
個人的な感想
HTMLページへのXSSのベクタを類別すると少なくとも3種類考えられます。ひとつはDOM構造の破壊、ふたつめはBOMへの不正介入、三つ目はその他の方法によるスクリプト注入です。
※見慣れない類別ですね。少々解説を。ここでBOMとは、ブラウザオブジェクトモデルのことを指します。例えばa要素にjavascript擬似スキームによるスクリプト記述を混入させることができるならば、BOMへの不正介入を許可していることになり即ちXSSベクタの成立を許していることになります。この時、DOMを壊しているわけではないことにご留意ください。ところでBOMの設計はブラウザごとに多型でありやっかいであることにため息をつくことがあります。
閑話休題。
長谷川さんの提起によるIEのinnerHTMLにおけるバッククォート問題は、ひとつめの類別のDOM構造の破壊に悪用されるタイプであると思います。
長谷川さんも例の解説記事で一番のポイントとして主張しているのですが、innerHTMLで取得した段階でその内容がDOM記述としてはぶっ壊れているわけでして、悪意ある者はその性質を使ってDOM構造の破壊を目論むXSSのベクタにするかもしれません。すなわちブラウザに欠陥があるということです。サーバサイドで防衛のためになんとかしてやろうというのは本来は筋違いです。Microsoft社が欠陥を修正しようとしないのであるならば、「これはひどい」ということになるでしょう。
幕間
私がこうして日記をアップするとすぐさまyamagata21さんがアンテナで捕捉するのですがw
冗長なPoC
バッククォート問題についての2007年4月の長谷川さんの日記を読んだ際、私は非常に衝撃を受けました。長谷川さんのPoCを写してすぐさま理解に努めようとしました。こうした場合、私はPoCをさまざまに加工し本当に冗長なものにしてしまいます。どうせ私の貧弱な頭脳には記憶できないので、PoCそのものを冗長にしてその性質を自分なりにわかりやすくして保存するのです。後日そのPoCを見れば当時どのようなことに自分が留意したのかがわかりますので便利なのです。おととし作成したPoCを見つつ当時の自分をふりかえってみます。
冗長なPoC作成1
長谷川さんのPoCはHTMLファイルを開くと即時にスクリプトの混入が終わってしまいます。私は改造して、button要素を仕込み押下時点でinnerHTMLによる複写が行われるようにしたようです。当時の自分が何を考えていたのか思い出しますと、このHTMLを出力したものと想定するサーバサイド側では、通常のXSS対策用途のエスケープをほどこしているわけで、その時点では脆弱性が直接現れているわけではない、ということを意識していたようです。
冗長なPoC作成2
ついで、input要素のvalue属性の中身に適宜実体参照や数値文字参照をほどこして挙動をみたようです。「`」や「onM」など。どうやら検知しやすいかどうか知りたかったようです。これは危険と思ったようです。
冗長なPoC作成3
ついでimg要素でごにょごにょしたようです。意識としてはスラッシュによって属性追加が可能かどうかですね。innerHTMLで引用符が取り去られる可能性があるならばスラッシュの仕掛けでもなんとかと思ったらしいです。これは成功せず。私の無能ゆえ。
冗長なPoC作成4
input要素でスペースのかわりに文字参照で各種の「スペース相当」をつっこんで見たようです。こちらは調査未完。やはり属性追加手法。
冗長なPoC作成5
長谷川さんのPoCにはなかったhiddenなinput要素にバッククォートつきで異常なstyle属性を追加しようとしています。ふははははとコメント行に書いてあります。なにがおかしいのか忘れました。w
冗長なPoC作成6
長谷川さんのPoCをform要素でサーバに送った際の信号の中身を見ているようです。value属性の中身はどのようになっちゃっているのかな？と。似ているのではと。文字参照がほどける意味で興味深かったので。調査未完のようです。
結局
PoC作成2番まででひといきついたようです。明らかに根性なし。
結論
これサーバ側のシステムでなんとかできる問題じゃなかろうと確信したのでした。ま、innerHTMLなぞ使わないほうが良いのはセキュリティ以前の問題とか私は考えるのですが。偏見？。
冗長なPoC昨日作成版
あーぁと。（なぞ
