新生鳩丸掲示板♯

早い返信ありがとうございます。

selectedをベタ書きすると常にそれが選択された状態となってしまいますよね？

optionに同じものがあった時それをデフォルト表示するという仕様にしたいのですが・・。

>というか「そこをselectedにしたい」とおっしゃっていますので、トートロジーでしょうか。

？？トートロジーとはなんでしょうか？？

よろしくお願いします。

>このようなソースでtodofukenが北海道だったら、そこをselectedにしたいのですが、できますでしょうか？

>よろしくお願いします。

selected属性 を利用すると良いのでは？

http://bakera.jp/hatomaru.aspx/ref/html/element/option

というか「そこをselectedにしたい」とおっしゃっていますので、トートロジーでしょうか。

はじめまして、HTMLの質問はここでしていいのでしょうか？

今、登録されたデータを書き出した時表示するページを作っています。

<select name="todofuken">

　<option value="">

　<option value="北海道">北海道

　<option value="青森県">青森県

　<option value="岩手県">岩手県

　<option value="宮城県">宮城県

　<option value="秋田県">秋田県

</select>

このようなソースでtodofukenが北海道だったら、そこをselectedにしたいのですが、できますでしょうか？

よろしくお願いします。

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

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

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

> というだけですね。もちろん、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の方が含むのでは?