■
■CSSXSSとCookie
ユーザ側で可能な CSSXSS 対策を模索したことが
CSSXSSが発表された後、ユーザ側で可能なCSSXSS対策が少しでもあればいいのにと模索したことがあります。色々と情報を教えてもらった中に素晴らしいものがありました。情報元には許可を頂いていないのでここではお名前は出しませんが、内容だけ少し引用させて頂きます。とあるサービスがCSSXSSに対してどのように影響を受けているかの考察の一部です。一部省略ないし伏字ないし文面変更がはいっています。原文にはほど遠いです。(御教示頂きまして、謹んでリスペクトいたします。)
これはCSSXSS の実験です。つまり、 foo のサービスに脆弱性があることを示すものではありません。単に私が foo のユーザですので例に出しただけです。誤解なきよう願います。IEの性質を見るための実験です。
以上の条件を満たしている場合、上の領域内にあなたの foo における bar が表示されます。キャッシュが残ってると本実験では色々と差しさわりがあるので、設定をかえたらキャッシュをクリアして、この実験ページをリロードしください。
説明の便宜上 cookie の設定を最低レベルに変更したものの、「よりセキュアとされる設定ならば CSSXSS が起こり得ない」というわけではありません。CSSXSS は、cookie とは基本的に無関係です。
CSSXSSの罠ページ buz がファーストパーティ、センシティブな情報を持つ foo のページがサードパーティーであると呼びましょう。 fooには別途ログイン済みとしましょう。foo のページは Cookie での認証が必要だとして、buz による CSS の import による取得時点で、認証に失敗すれば、センシティブな情報が buz 側に漏れない、このように推測可能なわけです。【注意】Cookie での認証というところがポイントです。CSSXSSのターゲットはその種ばかりではありません。あくまで一部のサイトについての考察です。
ですので、サードパーティーの Cookie について強い制限がかかれば、一部のサイトに関しては、CSSXSSの被害を防止できる可能性があります。実際、冒頭にかかげた実験ではそれを強く示唆していますし、いくつか実験でも確認しました。で、調べ始めたのですが…
※ 実験について余談です。インポートされた外部スタイルシートは通常キャッシュにたまります。以後、同じ外部スタイルシートはキャッシュから取り出されることになります。スタイルシートをせっかく変更したのに効果が無い場合もあるのですが、それはキャッシュにたまっているせいでしょう。余談終わり。 ※
Internet Explorer 6 で Cookie を管理する方法
上記がまとまった資料となります。がっかりしたことに以下の記述が見つかりました。
[プライバシー] タブで指定した設定の影響を受けるのはインターネット ゾーンのみ
私としては、たとえば、はてな等、センシティブな情報を預けてあるサイトは、信頼済みサイトゾーンにいれてセキュリティ設定を「中」にしてあり、インターネットゾーンはセキュリティ設定を「高」にしています。はてな等では、[プライバシー] タブでCookieの管理が出来ないということになるのです。これでは、私の運用には使えません。また、ひとさまに喜んでお勧めできるものでもなさそうだと、深く調べることを断念したのでした。
サードパーティの Cookie をコントロールしづらいもうひとつの理由
とはいえ、この際ですので勉強を進めたのですけれど、やはり、サードパーティのCookieをコントロールしづらい、という事実が浮かんできました。[プライバシー] タブでのスライダで設定を既定値の「中」から、よりセキュアな「中-高」に変更したら、CSSXSS対策として、ずいぶん良さそうに見えたものですから…ところが。以下の文書を発見。
記事の見出し部分を抜書きしてみます。詳しくは先の文書をお読み下さい。
■P3Pの目指しているもの■理想と現実のギャップ■くせ者・コンパクトポリシー
実際、以下のような内容になっています。
■くせ者・コンパクトポリシーあとIE 6.0におけるP3Pの実装においてはもう一つ注意すべき点がある。それはP3Pでは推奨規定(必須ではない)とされている「コンパクトポリシー」への対応だ。この「コンパクトポリシー」とは、上記のXML化されたプライバシーポリシーの一部をさらに簡略化したもので、実際にはCookieデータの送受信時などにHTTPヘッダに埋め込まれてサーバからユーザエージェントに送られる。
ところが、IE 6.0ではこの「コンパクトポリシー」付きのCookieが送られると、Cookieの受け入れを全面的にブロックしていない限り無条件にCookieを受け入れてしまうのだ。プライバシーポリシーはユーザ側・Webサイト側双方のポリシーが一致して初めて受け入れられるもののはずなのに、これでは「Webサイト側がコンパクトポリシーを用意している」というだけでユーザ側はそのポリシーを押しつけられてしまうことになる。これではユーザ側はたまったものではない。しかもIE 6.0ではCookieがブロックされない限り警告(アイコン)が表示されないから、一般ユーザはそういった事態が起きていることすら普通は気づかないと思われる。
いずれにしても、このままの状態では「プライバシー保護機能」といってもまったく不十分な機能しか持たないことは確かだ。従ってP3P対応については、サーバ側で用意するデータの規格については一応の目処が付いたが、今後ユーザエージェント側のポリシー設定機能を中心にさらなる開発が求められるだろう。
[プライバシー] タブでのスライダで設定を既定値の「中」から、よりセキュアな「中-高」に変更してあったとしても、サードパーティのCookieがコンパクトポリシー付きならば貫通してしまう、こういうことになるわけです。これでは、Cookieが認証に不可欠なサードパーティなサイトからでもセンシティブな情報がCSSXSSで盗まれてしまいかねません。極めて残念なことでした。
もっと凝ればなんとかなりそうなのですが、とてもとても初心者の方にお勧めできるしろものにはなりそうにありません。その上、CSSXSSは本来Cookieとは無関係なケースでも被害にあうことがありえますから、「これでＯＫ安心万歳」な自衛手段になりそうにもないことも、思い出す必要があります。
余談ですが、いわゆるWebバグないしWebビーコンが、Cookieを補助手段として使っているとしましょう。ずる賢いところでは「コンパクトポリシー」をきっと付けてくるでしょうねえ。
CSSXSS 対処の為の更新プログラムが早く望まれる
いよいよ明日はCSSXSS発見から２回めのWindowsUpdateの日なのですけれど、期待通り、更新プログラムが出るでしょうか。
私が普段常用で使っているWEBサービスのうち、CSSXSSのせいでセンシティブな情報が漏れるところを３件みつけています。うち２件はIPAに報告済み(IEの修正が目標です)、うち1件は直接、WEBサービスに連絡済みなのですが…なにぶんにもサーバサイドの対応は非常に難しいのですよね。なんとかなりませんかねぇ。明日のWindowsUpdateに期待をしています。
■P=NP問題の完全解決
Ｐ＝ＮＰ を証明して1億円P=NP P(1-N)=0 ∴P=0またはN=1
ワロス。
このネタで笑う人が、この場末の日記の読者にどれほどいらっしゃるのか、いささか心許なしです。すみません、変なメモを日記に書いて。
P=NPであることの証明に成功した人は、その瞬間から、世界中の情報機関からマークされます。ヘタするとスパイ同士の闘争の中でウッカリ殺されちゃうかもです。例えば、コンピュータなどで使われる暗号を全て超高速に解読する為の基礎技術を持っていることを意味するからです。応用は勿論これだけではないのですけれど。100万ドルもらえる話は本当。以下に関連。マインスイーパ（御存知Windows付属の機雷掃海ゲーム）あたりの解析で一発当てますか？次の瞬間国際スパイ網に包囲されます。P = NP を証明したければ、マインスイーパが、NP-完全に属していることが既に証明されているので、あとは、マインスイーパの整合性問題が P に属していることを示すことになります。たぶん。整合性問題? ええと、全部開かれたマインスイーパの図面が与えられた時にそれが本物のマインスイーパを解いた結果出てくるものなのかどうか判定する問題です。うそんこかほんこかわかればいいのです。このアルゴリズムが多項式時間でいければＯＫ。この記事自体嘘かもしれないです。勘弁してくださいね。
