■

■IE：新手法CSSXSS、Google Desktopの情報が盗まれる恐れ…というかGoogleばかりでないです、ヤバイのは、こりゃ参りましたね。

2006-01-30 追記：2006年01月20日付けで以下の状態です。マイクロソフト社からの言明です。

有用な情報を適切な方法でご連絡いただき大変感謝いたしておりますが、Web サイト側での対応が困難である事が判明し、また、Internet Explorer の脆弱性が近々対応できる見込みであるため、Internet Explorer の修正により、この問題に対応する方向で作業を進めております。

(snip)

また、この問題の根幹となります Internet Explorer の脆弱性については、現在鋭意対応中でございますが、こちらのリリース時期につきましては、詳細をお伝えすることができません。

誠に申し訳ございませんが、何卒ご理解とお客様の保護にご協力の程よろしく お願いいたします。

もともとブラウザの問題ではあるわけで、私としても各ウェブサイト運営社側に対応を求めることは難しいと判断していましたので上の言明は有難かったです。追記終わり。

style要素の@importで、クロスドメインな外部スタイルシートファイルをインポート出来ることは当然です。addImportでも良いらしいですし。読み出したスタイルはJavaScriptでdocument.styleSheets(0).imports(0).cssTextを使ってハンドリングできます。さて、故意にスタイルシート以外のファイル、例えばHTMLファイルなどを読めるかどうかですが。私は自衛の為、以前試したことがあります。以上で述べた方法で秘密なアレが@importできてしまったら怖いではありませんか。結果としてまるっきし通用せずでした（遠い目）。ところで、InternetExplorerでは、この方法で読み込むファイルがスタイルシートに似た特徴を持っていると読めてしまうのですね！{とか}とか:とかが適宜はいっていれば良いらしい。で、こういうコードがはいっているページなら結構ありそうなわけですよ。そこに内緒にしておくべき情報がはいっていれば盗むことが原理的に可能になってしまいます。どうやらこういった手法に対してCSSXSSというネーミングをしているらしいのですが。@importは確かにクロスドメイン。ということで。

正直なところ、IEについてこれを直すのはちょっと厄介かもしれませんね。そのCSSファイルがVALIDであるかどうか検査するロジックをどこまで厳しくすれば良いのかという議論になるのではないかなあ。ん？IE独自の例の仕様、ファイルの内容を勝手にsniffするからいけないのかな？プレーンなテキストファイルでもタグが書いてあると勝手にHTMLファイルとして読んじゃう例のアレですけど。自衛策としてインターネットオプションの各ゾーンのセキュリティ設定で調節できるのかも…

というわけで以下の記事に対する反応でした。何にも検証していません。ふーん、フィッシング的な手法で誘導してGoogle Desktopに蓄えられている内容を盗るのでしょうか。しばらく既定値設定のIEでの巡回は禁止か？って私、Google Desktopなんて使っていませんが、同じことでしょ？原理を考えれば。どこでもそこでもなんでもかんでも盗られそう。ちょっと煽りすぎですか、そうですね。しっかしクエリーに}{とかを入れるとかはやっぱりあざといですね。

• ITmedia エンタープライズ：IEにまた脆弱性報告、Google Desktopの情報が盗まれる恐れ
• Google Desktop Exposed: Exploiting an Internet Explorer Vulnerability to Phish User Information

さてと、ゾーンのセキュリティ設定を見直して公開されているPoCを試してみますか…どうやら駄目っぽい。対策にならず…sniff周りではないらしいです。

追記：さっそくGoogle以外で個人情報が漏れるヤバげなのを発見しました。たった今IPAに報告しました。報告番号は[IPA#21753252]このCSSXSS手法、簡単すぎ。本当に脅威だと思います。サイト管理者さん達は要注意です。といっても防御の方法が見当たらないんですよね。IEのユーザスタイルシートなら!important出しまくりで防衛できるかとも思いましたが[IPA#21753252]のexploitはもっと強かった…

---

さらに追記：これはXSS系ではなく、CSRF援助系であろうと強く思います。名前を間違ったなあ、CSSXSSっておかしいよね？@importのリクエストをクロスサイトでリクエストフォージェリしているんですよ、きっと。

---

12/6追記：

CSSXSSにてMIXIを攻撃するDEMOがありました。（対処済みのよう）。CSRF系での応用のようです。このように簡単に使えてしまうのでとても怖いですね。サーバー側の対応はアドホックなものしか考えづらいところです。

yamagataさんちで知りましたが下記のリンクは一度対処済みになったもののversion2になっていて生きているそうです。危険なので行かないで下さい。頼みます。(なのでリンクははずしました。プロの人だけ行ってね。)

• CSSXSSでmixiのpost_keyをゲットする例 :: ぼくはまちちゃん

12/6追記終わり

---

12/9追記：

【重要】です。cleemyさんによる検証で凄いことがわかりました。UNICODE系列とANSI系列とのアレにちょい似ていたりする感想を持ちました。引用させて頂きます。

cleemy

多分 { がキモっぽいですね。{ が全く無いテキストは読み出せませんでした。 あと、少なくともローカルにおいたHTMLでは、@import したローカルのファイルが cssTextで読み出せてしまうので、圧縮したzipファイルとしてHTMLを配布するような場合とかだと、ローカルの任意のファイルを抜き取る事が可能ですね。抜きたいファイルのファイル名が分かってるのと、ファイルの中に { がある必要がありますが。 あとHTMLメールとか、やばそうです。

ごめんなさい、訂正します。攻撃用HTMLがUTF-8で記述されてて @import先がShift_JISの場合は、 { が全く無いテキストでも、「ボ」や「マ」などの 7B, 7D を含む文字があれば読み出せてしまいました。Shift_JISでページを吐くようなサイトはさらにヤバそうです

t_trace

cleemyさん、大変ありがとうございます。しかしよく気づきますね。感服します。 CMSはサニタイズルール変更で回避しようと思ってたのに……orz

引用元は、Taiyo@hatenaさんのところです。Underconstruction by Taiyo@hatena (2005-12-04)

つうか駄目じゃね？守る方法はサーバ側にはないし。JavaScriptの恩恵を受けたいWindowsユーザはIEを使ってはいけないことが決定的です。

12/9追記終わり

---

以下:12/10追記

addimportや@importでなくてもlink要素で出来るじゃん…とほほ。MS02-023 で対策されたはずの GM#004-IE (注：スタイルシート以外でも読めてたのだった)の系だったのね、今回のCSSXSSは。なるほど、前回のMS02-023ではリモートからローカルにだけ手出し出来ないようにしていたのかも。うーん。

<!-- saved from url=(0014)about:internet -->
<link id="oFile" rel="stylesheet" href="【TARGETURL】" disabled>
<script language="jscript">
onload=function () {
    alert(document.styleSheets.oFile.cssText || "Could not extract any text from file.");
}
</script> 

---

以下:2006/01/30追記

addimportや@importやlink要素以外にxml-stylesheetも攻撃ベクターになることが判明しています。htmlばかりでなく拡張子がxmlのファイルもいかんということで、以下に例を。

• XML(XHTML)ではどうなのか

いずれにせよ、根本原因はIEでinvalidなスタイルシートをjavascript【等】を通じて読み出せる仕組みなので、どの攻撃ベクターも等価です。

また、一部のマルチバイト系コードの言語の場合、{ や } を取り除くような（Googleデスクトップが対応したような）やり方ではサーバ側のワークアラウンドにはならないこともわかっています。カタカナの「ボ」や「マ」などを考えてみるといいかもしれません。ゆえにサーバ側対策は極めて困難、ブラウザ側（IE）の対応が不可欠必須であることが結論付けられます。

追記終わり

---

以下:2006/01/30追記(その2)

上記まででちょっと防衛上不確かでまずい記述が、あるいはあるのではと冷や汗をかいております。IEのJavaScript(=Jscript∈ActiveScript)を単純に切っていても防衛にはなっていない可能性があるからです。別な言い方をすれば単純に、JavaScript の same origin セキュリティの穴とは言い切れないということになります。確認が必要かも知れません。

良く見られるCSSXSS(この名前自体、ことの本質を曲げていると思いたいのですが)の解説では、 JavaScript で、悪人が罠として用意したサイトのページにユーザが訪問した際に、悪意のサイトの自ドメインのdocument.styleSheets(0).imports(0).cssTextを通じて、被害者ターゲットのサイトの（ログイン中、あるいはBasic認証中などでのみ見ることが出来る、本来秘密であるべき）情報を抜き取るというものです。罠サイトページの DOMに IEのスタイルシート読み込みの欠陥を悪用して、スタイルシート以外の情報、たとえば、(X)HTML出力やJSファイル、XMLファイル等をブラウザの DOM に蓄積できるわけです。この蓄積の行為そのものは、スタイルシート読み込みの機能ですから、javascriptをオフにしていても実行されます。余談ですが、いわゆる、世間が思っているクロスサイトスクリプティングのようにターゲットの被害者ページに自由にスクリプトやHTML要素・属性を挿入するわけではありません。被害者ページからスタイルシートとして情報を盗んでくるだけなのです。（被害者サイトに何も挿入しなくとも実際に情報を抜き取ることが出来る in the wild な 実証コードを私は IPAに届け済みで、動作が確認され、受理されています。もちろん、例えば被害者サイトの検索画面等から特定符号をつっこむような特殊なURLを含む罠ページのほうが攻撃者は作成が楽チンでしょうけれど、必ずしもそのような挿入は必須ではありません。)このスタイルシートの読み込み時点では、繰り返しになりますが、JavaScriptは必要ではありません。

さて、 DOM と言えば、思わずJavaScriptを連想することが多いもしれません。ですが、 DOM のハンドリングでは、必ずしも JavaScript が必須というわけではありません。 一例ですが、JavaScript を使わず Java アプレット経由でブラウザの DOMに アクセス可能であると聞き及んだことがあります。これは Java アプレットの脆弱性ではなく仕様であるということと伺っています。

私はプログラミングの知識は皆無に等しいのでなんとも確認のしようもありませんが、ひょっとしたら次のようなことが起こり得るのではないでしょうか。

1. 悪意あるページを作成。被害者ページからスタイルシートで情報を抜き取る。
2. 悪意あるサイトの自ドメインの罠ページ閲覧中のブラウザの DOM を、Java アプレットで制御して、document.styleSheets(0).imports(0).cssText 相当を読み取る。

以上は実験もしていませんし、Java アプレットの仕様も確認していません。(特にMS謹製？が気になるところですが。)

煎じ詰めると、JavaScriptだけオフにしての IE で安心できるのかというとそうではないかもしれない、ということになります。本稿は多少なりとも FUD 気味ですが、そもそも、JavaScriptオフならば、通常はActiveX コントロールも切るのが正解でしょうから…老婆心まで。見知らぬサイトをIEで見に行くなら、定石通り、インターネットゾーンのセキュリティレベルを「高」にしてあれば宜しいかと思います。良く使うサイトは信頼済みサイトゾーンに追加した上で、信頼済みサイトゾーンのセキュリティ設定は「中」に。これで安心です。この対処方法はマイクロソフト社による提唱と同じです。御参考までにリソースへのポインタを。→ブラウジングと電子メールの安全性を強化する::Microsoft Security ホーム

また、JavaScript の same origin セキュリティの穴なのかどうか、自信が持てませんのでどうか御教示願います＞識者。また、少なくとも、JavaScriptは、今回の場合では、罠ページの自ドメインしかいじっていないはずです。

追記終わり

---

■はてな検索のウェブ検索機能追加部分にクロスサイトスクリプティング脆弱性

ウェブ検索機能追加が追加されたはてな検索にクロスサイトスクリプティング脆弱性がありました。既に2005年12月03日 11:04までには修正が完了しています。報告は05/12/02 21:45。土曜日なのにお疲れ様でした＞はてな。

http://search.hatena.ne.jp/websearch?word=%22%3E%3Ciframe%2Fsrc%3D%27http%3A%2F%2Fwww.google.com%27%3E%3Cq%2F%22

というような単純なもの。

そういや、expres/**/sionネタで、はてなが脆弱であることを、こないだ長期間IPアンリーチアブルであった時に知ったときには冷や汗をかいたものです。一時期に無理やりIP接続環境を探してあわてて報告したものでした。後に確認しましたが、このときもはてなさん、迅速に修正なさっておいででした。

■IE、Opera、Firefox、に関する、とあるCSS適用の実装の差（ネタ）

ネタですから。

IEにだけサイトのコンテンツを見せてやらないよ！という仕掛けの中で最も簡単なのは何だろうかとイタズラで考えたことがあります。はてなダイアリーで試したかったのでJavaScriptやらCGIやらは使えません。ならばCSSだけで振り分ければ良いというわけなんですね。色々テクニックがあろうかとは思いますがここは一発、以下のようにスッキリしたものをと。

<style>
* {
        display : inline ;
        display = none ;
}
</style>
<p>あ</p>
<p>い</p>
<p>う</p>
<p>え</p>
<p>お</p>

ええと、プロパティとその値との間のコロン(:)の替わりにイコール(=)を使いますと、IEでは有効なのですね。素晴らしいHackでしょ？上の例では、IEではいったん、全てに対してdisplayをinlineにした後、noneに上書きして見えなくしています。実際に試すと思ったとおり何も見えなくなってイタズラ成功か？と嬉しくなったのですが…

ええと、Operaでは期待通り、displayはinlineになります。普通の段落の表示であるブロックが取れちゃって、inlineですから、あいうえおが横一列にならびます。ところがですね、Firefoxでは全く予想しなかったことが起こりました。大体において以下のように表示されます。

* { display : inline ; display = none ; } あ い う え お

よもやスタイルが表示されようとは！！！

しかして、もっと恐ろしいことが。表示された部分(一行)をコピーしてメモ帳に貼り付けたらスタイル部分は消えてしまって、あ い う え お は改行されていました。以下のような感じ。

あ

い

う

え

お

いやあ、どうやらdisplay:inline; も効いていない感じなのですが…はて？でもね、ひょっとしたらFirefoxのほうが正しい挙動だったりしますか？いや、メモ帳に貼り付けたらのところは別にして、style要素の中身もdisplay:inlineが効いてしまうのが本来だったりします？教えてエライ人。

というわけでIEへのネガティブキャンペーンは中止。(あくまでネタです。)

このお話、なんばりょうすけ さんとこでうけて頂きました。考察がついています。児童小銃 .456(20051206)

■スタイルシートでテキスト汚し効果

テキスト汚し - 186(000)を拝見。見出しのテキストを隠しつつ(背景)画像とかでなんとかしちゃうもの？ただhtmlが<h2><span></span>Worn Text</h2>と空spanが入って気持ち悪いというsmoking186さんの御意見はご尤も。このテキスト汚しは、ひょとしてUsing Background-Image to Replace Text - Stopdesignにかなり近いと思っています。Using Background-Image to Replace Text ではspan要素の中身をspan {display:none;}として見えなくしてしまい、替わりに背景画像がこんにちは、という感じなのですが。テキスト汚しでは、span {display:none;}は、たぶん？しなくても大丈夫作戦でしょうか。気になることがあるのです。スクリーンリーダーで閲覧するとどうなるのかという視点です。この辺ハッキリしないのですよね。IBMのリーダーだとIEのエンジンで解釈した後に発声してくれる仕組みだったかと思うのですが（間違いならごめんなさい）そうなると{display:none;}な見出しのテキストはヘタすると読まれません。無論背景画像も無視しんこちゃん。ということはHn要素の見出しのないコンテンツを提供していることになります。これは困ったちゃんなのですね。というわけでUsing Background-Image to Replace Text はボク的にはちょっと意見を保留したい手法なのです。一方、テキスト汚しでは、{display:none;}は、しないのでスクリーンリーダには優しいですよね、少なくとも。背景画像は無視されることでしょうし。適当に汚して透過している背景画像をテキストにオーバーレイするだけなのでしょうし。(ユーザスタイルシートを使った場合にどうなるのかちょっとわかりませんが大丈夫なのかな？)

ところで空spanが入って気持ち悪いというお話でしたっけ。Image Replacement?No Span - CSS Playという改良型があって、空spanは使っていなそう。<h3 id="ex1">Example Text for the Image Replacement</h3>な感じにスタイルを定義してしまう系統。問題は、{height: 0;}なテキスト（こうやって消すわけですが）をIBMのリーダが（他のスクリーンリーダが）きちんと読んでくれるのでしょうか？という心配だけになります。あ、そうか、テキスト汚しなら大丈夫なのかな？{height: 0;}で隠す必要もなし。ああそうか、Tantek's hack がひょっとしたらたぶん、はてなのスタイルシートでは使えないのかな？XSS対策でなんでもかんでもバックスラッシュ殺しまくってますから。はてさて。

実際にコード書いて確認しているわけではありませんのでエエカゲンです。すみません＞smoking186さん、皆さん。