新生鳩丸掲示板♯

> というだけですね。もちろん、MSIE 必須かつスクリプト必須のサイトは利用できませんので、それについてはパッチ待ちとなります (まあ、そんなサイトそうそうありませんが)。

ところが対策案の一部にはJavaScriptでhiddenフィールドにワンタイムトークンを突っ込むなんてものまでありましたね。もう本末転倒の極みというか何考えてるのかさっぱり分かりませんが。

>> document.domainを自ら検査し、あらかじめ決められているドメイン以外なら、

>とりあえずFirefoxの場合ですが、こういうのには対応してますか? してないほうに2セント賭けますが【謎】。

>HTMLDocument.prototype.__defineGetter__("domain", function(){return 'www.example.com';});

HTMLDocument.domain を参照すると、'www.example.com' が返って来るように細工するですか…こんな乗っ取りじみたこと…(絶句)

　あー、なんか閉鎖されちゃっていますね。

>「開発者のための正しいCSRF対策」というタイトルで文章を書かせていただいたのですが、大垣 靖男様より名誉毀損の可能性を示唆されましたので、公開を中止致します。ご迷惑をおかけして大変申し訳ありませんでした。

　そのページにリンクする形で追記したので、閉鎖されると意味がわからなくなってしまうのですが……。

　面倒ですが、CSSXSS の説明ページを追加して、そこにいろいろ書きますかね。

>なんで迷惑なのを知ってるんですか? IPAの中の人ですか? なら迷惑なのでソフトウェアベンダが直すと言ってるものを送らないでくださいと返信してあげればいいと思います。

　ちなみに、お門違いな届出は単純に不受理になるだけです。

　受理/不受理の判断も含めて IPA のお仕事なので、届け出ること自体はなんら問題ないと思います。

> document.domainを自ら検査し、あらかじめ決められているドメイン以外なら、

とりあえずFirefoxの場合ですが、こういうのには対応してますか? してないほうに2セント賭けますが【謎】。

HTMLDocument.prototype.__defineGetter__("domain", function(){return 'http://www.example.com/';});

Firefox 1.0～1.0.2にあった脆弱性の対応は、chrome vs. contentの場合にこの種の乗っ取りを不可能にするものでした。content vs. contentに関しては今でも仕様とされています(権限上昇するわけではないので)。

IEについては調べてませんが、

http://dean.edwards.name/IE7/

のようなことができるくらいなので、できるに違いないとは踏んでいます。

＞JSファイルはCSSXSSなんか使わなくてもクロスドメインで読める「仕様」だというのは以前そちらの日記【何処】に書いたと思いますが。

はい、その節はありがとうございました。その結果、某サイトは、'CSSXSS'を使わない、えむけいさんがおっしゃる方法による、アクセスからは、秘密情報を漏らさないようにJSファイルの中身を変更してい対応していました。

現在そのサイトでは、CSSXSSがなければ安全です。

ええと、ざっくばらんに言えば、そのJSファイルが、JSとして読み込まれれば、document.domainを自ら検査し、あらかじめ決められているドメイン以外なら、自分自身に記述してあるユーザのセンシティブがデータをnullで置き換えるというものです。そのソースを見たときには、ポンとひざを打ちました。こうしておけば、罠ページにあるJSからは、被害者サイトのJSがもたらすデータを取得してもnullになってしまいます。

>非ASCII文字以外は

「非ASCII文字は」の間違いです

> たとえば…JSファイル。

JSファイルはCSSXSSなんか使わなくてもクロスドメインで読める「仕様」だというのは以前そちらの日記【何処】に書いたと思いますが。

> Shift_JISなんかですと、難しかったりするかもしれません。

そこで非ASCII文字以外はすべて文字参照ですよ(もちろん { も)。文字化けも発生しなくなって完璧です。

まあ実際にそうしろと迫られたら私だったら断りそうですが【謎】。

> だからってすべての { が出るサイトが対応しないといけないの？

すべての添付ファイルが使えるWikiは対応させられそうな勢いでしたね。

> って、そんなのでいちいち指摘されてきたら迷惑なんですけど。

なんで迷惑なのを知ってるんですか? IPAの中の人ですか? なら迷惑なのでソフトウェアベンダが直すと言ってるものを送らないでくださいと返信してあげればいいと思います。

> なんといいますか、この穴、イヤすぎです。

IEには他にも色々な穴があります。

ウェブアプリサイドで対策できる穴もあれば不可能な穴もある。

XSSCSSはなまじ { を削るとかで対応できてしまうものだから、

対策するウェブサイトもあったと。Google?

だからってすべての { が出るサイトが対応しないといけないの？

> IPAに報告済みです。

って、そんなのでいちいち指摘されてきたら迷惑なんですけど。

マイクロソフトが直さないって言ってるならともかく、

直すって言ったんでしょ？

ええとトピックの主題からははずれます。CSSXSSばなしです。CSRFはよけておきます。

>　ただ、「CSSXSS」については私の中でもまだ完全に消化されていない感じで、議論はこれからという感じですね。たとえば、{} が無ければそれで大丈夫なのかとか、いろいろ検討すべきことがありそうです。

1.そういえば某カタカナを壊さないようにしなくてはというお話とかがありましたね。罠ページがUTF-8で記述されてて @import先がShift_JISの場合、 { が全く無いテキストでも、「ボ」や「マ」などの 7B, 7D を含む文字があれば…被害者ページがShift_JISでページを吐くようなら…単純に{}だけ切り飛ばせば良いのかは微妙な問題です。

2.盗み出されるデータはHTMLでなくとも良いのです。このへん世間様ではあまり意識されていないと思います。たとえば…JSファイル。ログイン後、そのユーザにみあった秘密情報を含むJSファイルをサーバから適用している時には、そのJSファイルの内容を簡単に盗み見ることが出来てしまう可能性があります。{}等をカットすることは、この場合には不可能です。いや、実例がありまして、昨年１２月にIPA宛てに通報いたしました。

3.はまちちゃん exploit on はてな　では、検索窓から{}等を突っ込んで返ってくるページにログイン済みユーザの名前が出ているから取れちゃうよ～というお話でした。{}を文字参照してあれば大丈夫だったかもしれません。攻撃者側がなんらかのinsertionを行った罠を作成し被害者を誘導することがあるわけですから、静的なページはともかく動的なページでも配慮が必要となってしまいます。ことは検索などのフォームに限りません。たとえば、Webメールサービスでは、件名に{}等をつっこんだ悪意あるメールを被害者個人に送っておき、その直後に別途用意した罠ページをふませることで、被害者の受信メール一覧を盗み出すことが出来てしまうかもしれません。あるいは、返信をさせて、送信済みメールの一覧を盗み出すとか。これは実例がありまして、IPAに報告済みです。件名に含まれる{}をとっぱらったり文字参照すればよかったのかといえば、Shift_JISなんかですと、難しかったりするかもしれません。

なんといいますか、この穴、イヤすぎです。

>>ある意味 XSS よりも危険です。

>そうでしょうか?

>IEにXSSがあればDOMで同じことができるのでXSSの方が含むのでは?

　そうですね。「IEにXSSがあれば」という状況が何を仮定しているかにもよりますが、それがたとえばいかなるゾーンでも攻撃者の任意のスクリプトが動作するという話であれば、その方が危険でしょう。

　ただ、私がいわゆる「CSSXSS」で注意しなければならないと思っているのは、スクリプトがターゲットのサイト上で動作する必要がないという点です。

　たとえば、インターネットゾーンで完全にスクリプトを無効にしていたとしますと、そのサイトに XSS 脆弱性があったとしても、攻撃者が情報を盗み出すことは難しくなります。

　しかし、いわゆる「CSSXSS」では、イントラネットゾーンに悪意あるスクリプトを置いてインターネットゾーンのサイトの情報を引き出すようなことが可能です。

　こういった面があるので、「ある意味」危険と評しています。

>ご参考【謎】:

>http://www.oiwa.jp/~yutaka/tdiary/20060330.html#p01

　おおむね同感ですね。

　基本的に、CSRF といわゆる「CSSXSS」とは別の問題です。CSRF がなくても CSSXSS は問題になりますし、逆に、CSSXSS の対策がされているならば、「高木方式」で CSRF 対策しても問題は起きないはずですし。

　ただ、「CSSXSS」については私の中でもまだ完全に消化されていない感じで、議論はこれからという感じですね。たとえば、{} が無ければそれで大丈夫なのかとか、いろいろ検討すべきことがありそうです。

DTDにはあるように見えますし、属性索引にもDLは含まれていますが、Errataには出ていませんね。公式のMLがあるはずなので、一応そこにも投げてみるとよいかもしれません。

ご参考【謎】:

http://www.oiwa.jp/~yutaka/tdiary/20060330.html#p01

>ある意味 XSS よりも危険です。

そうでしょうか?

IEにXSSがあればDOMで同じことができるのでXSSの方が含むのでは?

ちょっと前に出ていたimage/jpeg内のスクリプトが実行されるというののとか、Wikiで添付にContent-Dispositionを付けないと脆弱だというのも本来は特定ブラウザの問題ですよね。officeさん【誰】はtext/plainに関してよく対策を迫ってましたが。

Content-Dispositionを付けても(Safari等が)脆弱だというのは特定ブラウザの問題として無視されてますね。

FYI

●開発者の為の正しいCSRF対策::金床さん

http://www.jumperz.net/texts/csrf.htm

●CSRF対策のML Sea Surfers ML

http://www.freeml.com/ctrl/html/MLInfoForm/seasurfers@freeml.com

開発者の為の正しいCSRF対策のページを更新していくためにSea Surfers ML を作ったとか。これだけでも凄いですね。超期待です。

　アレな発言をするだけではなんですので。

　HTML鳩丸倶楽部、XHTML鳩丸倶楽部のHTMLリファレンスについて質問です。

　最近仕様書を確認したのですが、dl要素にはcompact属性は定義されていないのではないでしょうか。

http://www.asahi-net.or.jp/~SD5A-UCD/rec-html401j/struct/lists.html#h-10.3

（以下は引用）

>>開始タグ: 必須、終了タグ: 省略可能

>>

>>別途定義がある属性

>>

>>id、class (文書内識別子)

>>lang (言語情報)、dir (テキスト方向)

>>title (要素情報)

>>style (行内スタイル情報)

>>onclick、ondblclick、 onmousedown、onmouseup、 onmouseover、onmousemove、 onmouseout、onkeypress、 onkeydown、onkeyup (組込みイベント)

>>定義リストは他の形式のリストとは少しだけ異なり、リスト項目が、用語と記述という2つの部分から構成される。用語はDT要素で示され、行内内容に制限される。記述は、ブロックレベル内容を取るDD要素で示される。

　念のためにW3Cのほうも探してみた。

http://www.w3.org/TR/html4/struct/lists.html#h-10.3

（以下は引用）

>>Start tag: required, End tag: optional

>>

>>Attributes defined elsewhere

>>

>>id, class (document-wide identifiers)

>>lang (language information), dir (text direction)

>>title (element title)

>>style (inline style information)

>>onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events)

>>Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the DT element and is restricted to inline content. The description is given with a DD element that contains block-level content.

　ul、ol、liの各要素にはtype、start、value、compactの各属性が登場しますが、dl、dt、ddの各要素にはそれらの属性が定義されていないように受け取れます。

　どちらにしろtype、start、value、compactの各属性は「非推奨」ですから、StrictなHTML文書を作るには無視することになるので問題がないといえばないのですが、気になりましたので確認させてください。

　仕様書の読み方が付け焼刃なので間違っていたらごめんなさい。

　コメントも突込みどころ満載ですね[謎]。

＃T氏が実は名前を変えて活動中なんてことはないと思いますが[謎]。

　それはさておき、あくまでも一読者の希望ですのでばけらさんのご迷惑にならないようにお考え頂ければ結構です（最近は某I**とか某Tipsでも続編は掲載されていないご様子ですので、ついつい）。