新生鳩丸掲示板♯

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

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でも続編は掲載されていないご様子ですので、ついつい）。

始めまして「コピペで飾ろうホームページ」管理人のhideと申します。

当サイトについての批判をご検討のようですが当サイトは「yahoo japan」,「yahoo kids」様に登録して頂いています。

当サイトへの批判は登録して頂いているサイト様及び相互リンク

して頂いていますサイト様にも被害が及ぶ可能性があります。

「コピペで飾ろうホームページ」への批判をご検討中でしたら

御遠慮願います。

当サイトへのご不満ご意見がありましたらサイト内「お問い合わせ」

または記入させて頂きましたメールアドレスよりご連絡下さい。

可能であれば早急に改善いたします。

>　以前の「鳩丸ご意見番」にあったようなトンデモ解説書のぶった切りをまた拝読したいですが、いかがでしょうか？

　余裕があればやりたいですね。

# 実はやりたいことはとてもたくさんあるのですが、あまり手がつけられていないという……。

>＃＃連投ですいません。半角英数のみのハンドルを使ってたらブロックされてしまったので名前を訂正させていただきました。

　それでも誤爆していたようですみません。

　フィルタをちょっと調整してみますね。

　以前の「鳩丸ご意見番」にあったようなトンデモ解説書のぶった切りをまた拝読したいですが、いかがでしょうか？

http://copicopi.com/

とか、突込みどころ満載ぽい”初心者向け”解説サイトがいまだに大手を振っている様子ですので。

＃ここ１年ほど拝読しておりますが（旧鳩丸倶楽部から移転する前後あたりから）、書き込むのは初めてです。

＃ご意見番の各文書については非常に参考となり、時々URLを紹介などさせて頂いています。

＃＃連投ですいません。半角英数のみのハンドルを使ってたらブロックされてしまったので名前を訂正させていただきました。

あの翻訳サイトは、サイドバーばりばりだし。

紺屋の白袴でしょうか。

>いちばん下のほうの「AJAX 用のリンク、「最初に戻る」、障碍者ユーザのためのスキップ・リンク」のリンクテキストが、はげしく見えづらくて驚きました[謎]。

そもそもそ【謎】せっかくヤコブ博士【誰】が「リンクテキストは青色にしよう」と主張しているのに【謎】訳者【誰】が個性的な色遣い【謎】をしているせいで台無しです【謎】。主張そのものの当否はともかく【謎】。

あ、スタイルシートオフのときにどうするんじゃという考えが浮かびましたが、私の以前の考えでは、そういう人（誰）は恐らくユーザスタイルシートを使うから大丈夫じゃね？とか思いました。

テキストベースのブラウザはどうするんじゃ？とか疑問に思いますが、これは誰かエライ人から解決して欲しいかもです。

フラグメントIDへのリンク【が】わかりにくい

いえ、少々か大分か不明ですけれど私はHTML学習困難な人なので。「フラグメントIDへのリンク【が】わかりにくい」とマジに学び始めた頃悩みました。今も学び始めた頃の真っ最中ですけれど。(青春)

始点アンカーと終点アンカーが何故同じ要素で表現されますか？と激しく混乱したものです（遠い目、但し未だに時々不安になります。）。

ん～外部サイトから自分のHTMLのフラグメントへの参照があると嬉しいですから、フラグメントそのものは悪じゃないと思います。問題はページ内へのフラグメント参照をどのようにページ外への参照と区別したらよいのだろうかということなのではないかと。始点アンカーと終点アンカーが別要素になっていて、しかも始点アンカーからページ内の終点アンカー(フラグメント)へのスタイル宣言が、上手に決められて、ページ外への始点アンカーと区別しやすければ、良かったのになあと思っています。

いちばん下のほうの「AJAX 用のリンク、「最初に戻る」、障碍者ユーザのためのスキップ・リンク」のリンクテキストが、はげしく見えづらくて驚きました[謎]。

[quote]

建国「記念日」ではなく「記念の日」なのは、史実に基づく建国の日とは関係なく、建国されたという事象そのものを記念する日であるという考えによるものである。

[/quote]

( Wikipedia より )

知りませんでした。勉強になりました。