新生鳩丸掲示板♯

bakera.jp > 新生鳩丸掲示板♯ > スレッド内全記事表示 (記事 3450 からのスレッド)

スレッド内全記事表示 (記事 3450 からのスレッド)

[3450] Re: 「CSRFの説明に追記」

えむけい (2006年3月31日 3時25分)

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

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

[3451] Re: 「CSRFの説明に追記」

A (2006年3月31日 3時55分)

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

そうでしょうか?

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

[3452] Re: 「CSRFの説明に追記」

えむけい (2006年3月31日 4時9分)

[3454] Re: 「CSRFの説明に追記」

ばけら (2006年3月31日 14時23分)

 おおむね同感ですね。

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

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

[3455] Re: 「CSRFの説明に追記」

ばけら (2006年3月31日 15時13分)

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

>そうでしょうか?

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

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

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

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

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

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

[3456] Re: 「CSRFの説明に追記」

スターダスト (2006年4月1日 13時30分)

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

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

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

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

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

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

[3457] Re: 「CSRFの説明に追記」

通りすがりその1 (2006年4月1日 23時25分)

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

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

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

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

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

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

> IPAに報告済みです。

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

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

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

[3458] Re: 「CSRFの説明に追記」

えむけい (2006年4月1日 23時45分)

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

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

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

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

[3459] Re: 「CSRFの説明に追記」

えむけい (2006年4月1日 23時51分)

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

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

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

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

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

[3460] Re: 「CSRFの説明に追記」

えむけい (2006年4月1日 23時52分)

>非ASCII文字以外は

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

[3461] Re: 「CSRFの説明に追記」

スターダスト (2006年4月2日 21時18分)

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

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

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

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

[3462] Re: 「CSRFの説明に追記」

えむけい (2006年4月3日 2時26分)

> 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/

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

[3463] Re: 「CSRFの説明に追記」

ばけら (2006年4月3日 11時15分)

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

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

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

[3464] Re: 「CSRFの説明に追記」

ばけら (2006年4月3日 11時25分)

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

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

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

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

[3465] Re: 「CSRFの説明に追記」

スターダスト (2006年4月3日 16時21分)

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

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

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

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

[3467] Re: 「CSRFの説明に追記」

えむけい (2006年4月4日 0時53分)

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

どうも__defineGetter__はJavaScript(ECMAScriptでもJScriptでもないMozillaの実装)でしか使えないようなので、特定ブラウザの問題として却下するという解も捨てきれません。

何でもありという意味での権限上昇は確かに起きませんが、本来できないはずのクロスドメインのアクセスを許してしまうというのは権限上昇と取れないこともないですね。

最近の日記

関わった本など