Mozilla、「CSS による Web ブラウズ履歴漏えい」をブロックする方向へ 29
ストーリー by reo
手を替え品を替え 部門より
手を替え品を替え 部門より
hylom 曰く、
「JavaScriptを使わずにWebブラウザの閲覧履歴を盗む」や「楽天・ドリコムの行動ターゲッティング広告、HTML/CSS仕様の不備を突いて訪問先サイトを調査」などで過去話題に上った「HTML/CSS仕様の不備」について、Mozilla が対策を行う方針で検討を進めるようだ (Mozilla Japan ブログ記事、Mozilla Security Blog の記事、Mozilla Developer Street (modest) の記事) 。
問題となっている「HTML/CSS仕様の不備」というのは、「すでに訪問済みのリンクを別の色で表示する」というもの。これは長らく使われてきた仕様であり、ユーザビリティの向上にも役立っている。しかし、たとえばページ内に大量の隠しリンクを埋め込み JavaScript でその表示状態をチェックする、といった手法を用いることで、URL に対し訪問の有無をチェックできてしまう。
これに対し Mozilla は、「リンクへの訪問の有無で変更できるスタイルを色のみに制限する」「レイアウトエンジンに手を入れ、リンクへの訪問の有無によるレイアウト処理フローの違いを無くす」「JavaScript で取得できるスタイルを制限する」といった対策方法を提案している。これらの変更が行われても多くの Web サイトは問題なく動作するとし、またいくつかのサイトでは「訪問済みリンクの表示」が若干変わってしまう可能性はあるものの、大きな問題にはならないだろうとしている。これは、「訪問済みのリンクの色を変更する」という有用な機能を大きく損なわず、そしてプライバシ問題に対処できるという「良いトレードオフだ」とのことだ。
WebKitも (スコア:2, 参考になる)
https://bugs.webkit.org/show_bug.cgi?id=24300
教えて偉い人 (スコア:1)
Re:教えて偉い人 (スコア:2, 参考になる)
結局、最小限だけ削るとこうなる、ということかと。
まず、ページ内の要素の座標を取得不可能にするのは影響が大きすぎるから無茶です。 ボタンの上にマウスカーソルを持って行くとメニューが開くようなページなど、まともに動かなくなるページが多数で。
次に、ページ内要素の座標が得られるなら、 「リンクへの訪問の有無で変更できるスタイル」にページのレイアウトが変わっちゃうようなスタイルを含めるのは危険です。 「リンクの訪問無しなら幅が0、有りなら幅が100」と言うような要素を置いておくと、周辺の要素の表示位置が訪問の有無で変わってくるため、Javascriptから検出できてしまいます。
ということで、この「良いトレードオフ」が導かれます。
Re:教えて偉い人 (スコア:1, 参考になる)
既存のサイトがいろいろ残念な事になります。あとJavaScriptを使わなくても履歴を盗む方法があるというのは関連ストーリーにも載ってるFAQです。たまたま攻撃にJavaScriptが使われてるからとにかくJavaScriptから機能を削るのはたまたまGumblarが攻撃の対象にしてるからFFFTPをアンインストールするのと同じくらい似非セキュリティです。
JavaScriptの制限をCSSにも適用すれば良いだけでは？ (スコア:1)
:visited疑似クラスに対して適用可能なプロパティを制限するのは、意味ないですよね？
getComputedStyleした後に適用可能なプロパティ（colorとか）が違うか見れば良いだけですし。
かといって、getComputedStyleを制限するのは悪影響が大きすぎませんか？
普通のページならともかく、ウェブアプリだと挙動がおかしいものが出てくる気がします。
というか、:visitedをブラウザのグローバルな履歴に対して判定しているから履歴が漏れるのであって、
JavaScriptのドメイン制限のように、ドメインごとに分けられた履歴で:visitedを判定するとか、
ブラウザ開発者なら一番最初に思いつきそうな対策をあえて避けるのはなぜ・・・？
# iframeとJavaScriptを組み合わせると、アクセスしてきたPCでHTTPサーバーが起動しているか調べられますよね。
# Internet ExplorerとMozilla Firefoxでは、onloadイベントは接続が失敗したときには発生しないので。
# （ChromeとOperaでは接続に失敗してもonloadは呼ばれます）→テスト [jaist.ac.jp]
Re:JavaScriptの制限をCSSにも適用すれば良いだけでは？ (スコア:1, 参考になる)
> :visited疑似クラスに対して適用可能なプロパティを制限するのは、意味ないですよね？
いいえ。
> getComputedStyleした後に適用可能なプロパティ（colorとか）が違うか見れば良いだけですし。
それはできないように対策されています。
> かといって、getComputedStyleを制限するのは悪影響が大きすぎませんか？
取得ができなくなるわけではありません。違うかどうかが判定できないだけです。具体的には訪問済みリンクのスタイルを見ても、未訪問の場合と同じスタイルが返されるようになっています。ですから初めて訪問したときにちゃんと動作するサイトなら、ちゃんと動作します。
ではなぜ適用可能なプロパティの制限が必要なのかというと、たとえば訪問済みリンクのボックスのサイズを変えて、親要素のサイズ変更を検出するという攻撃が考えられるからです。この場合リンクが未訪問だと仮定したレイアウトを内部的に計算して保持するのはコストが高すぎて現実的ではありませんし、実際に画面に表示されているものとズレが生じたら傍目にはバグにしか見えないでしょう。
またたとえば背景画像の有無によってスタイルの適用速度にはっきりとした差が現れれば、時間計測によってスタイルの推測が可能です。ですから訪問済みの場合と未訪問の場合で、レンダリング時間がほぼ同じになるようなスタイルの変更しかできないように制限されています。
> ドメインごとに分けられた履歴で:visitedを判定するとか、
RequestPolicyを使ってるとわかりますが、今どきのサイトは静的コンテンツのみ別サーバに分けてるとか実体はamazon AWS上にあるとか当然のように行われていて、あまり現実的ではありません。
リンク集を見てもどの外部サイトが訪問済みなのかわからないというのは大きく利便性を損ないます。それをサイトに知られたくないだけであって。それでもいいという人向けのアドオン [mozilla.org]はありましたが、デフォルトで採用できるような代物ではありません。
このバグは修正までに8年近くも検討が重ねられてきたわけですが、みなさんよほど「ぼくのかんがえたさいきょうの」攻撃/対策に自信がおありのようで。
Re:JavaScriptの制限をCSSにも適用すれば良いだけでは？ (スコア:1)
説明の仕方が悪く「ドメイン内のリンクだけ:visitedを判定する」と伝わってしまったようで申し訳ない限りです。
私が意図したのは「サイト毎に履歴をとって、それを元に:visitedを適用する」ということです。
（ユーザーのナビゲーション用とは別個にCSSの計算専用の履歴として、privateな履歴を記録する）
ここで問題になるのが、どこからどこまでが1つの「サイト」なのかという判定条件ですが、
元コメでは安易に「ドメイン」と書いてしまい誤解を招いてしまいましたが（発想が古い）、
XMLHttpRequestのアクセス制限と同じ判定方法で判定する、が具体的かつ正確だと気づきました。
ドメイン単位ではありません。
なので動作的には、
となって、レスにかかれたようなデメリットやクラッカーとのいたちごっこを考える必要がないという訳です。
サイト毎の「内」と「外」を分けるという方法はCrossなんちゃらの対策としてはまっとうな方法だと思うんですが
「サイト固有CSSの:visitedをグローバルな履歴に基づいて適用したブラウザの実装」がバグでなくて、
「:visitedが指定できるCSSの仕様そのものがセキュリティホール」となってしまった経緯が知りたいのです・・・
Re:JavaScriptの制限をCSSにも適用すれば良いだけでは？ (スコア:2)
#1744154 [srad.jp] の人が紹介してくれている SafeHistory [mozilla.org] はその方法です。 SafeHistory ではドメインごとに「そのドメインにあるリンクを辿ることによってページを訪れたことがあるかどうか」で visited スタイルを適用するかどうかを決めます。
この方法の問題点は、もちろん訪問済みページへのリンクが visited スタイルで描画されないことがある (そういう変更何だから当たり前) ことと、「サイト」と「ドメイン」は違うということでしょう。後者については、一つのドメインを複数のサイトで共有していたり、一つのサイトが複数のドメインにまたがっていたりすると、期待通り動かないことは理屈上はあり得ます。実際どれだけ問題かは僕は検証したことがありません。
#1744154 [srad.jp] の人が
と言っている通り、まあ素人がぱっと思いつくことは誰かが既に試していると思って間違いないでしょう。べつに 8 年かかったからといって 8 年間ずっと考えていた結果というわけではないので、誇張が入っている気がしますが。
Re: (スコア:0)
それだと :visited の意味が変わりすぎ。削る方がマシ。
自分の使い方を一般化しないでくれ。
Re: (スコア:0)
> 説明の仕方が悪く「ドメイン内のリンクだけ:visitedを判定する」と伝わってしまったようで申し訳ない限りです。
いいえ。理解もしてますしちゃんと伝わってます。自分で
> ブラウザ開発者なら一番最初に思いつきそうな
と言ってるくせに、目の前の愚かなACはわざわざ太字で二回も強調しないとこんな簡単なことすら理解できないとでも思ってるんですか? 自惚れが過ぎるんじゃないですか?
> XMLHttpRequestのアクセス制限と同じ判定方法で判定する、
XMLHttpRequestは基本的にドメインをまたげませんけど? ドメインがなんだかわけのわからな
Re: (スコア:0)
技術的な事は詳しくないけど、
え～。これじゃぁ他のサイトへのリンクは既読か分からなくなるって事でしょ。
どう考えても同じサイト内の既読判別だけじゃ不満ですよ。ソーシャルブックマークや/.みたいな掲示板で紹介された外部リンクが既読かどうかわからないなんて、意味無いでしょ。
CSS仕様はともかく (スコア:0, フレームのもと)
HTML仕様の不備って何?
HTML仕様でできたのは色を変えることだけだったと思うんだけど(body要素のlink属性とvlink属性)。
Re:CSS仕様はともかく (スコア:2, 参考になる)
「要素の現在の状態（色等の属性）を取得できる」と言うJavaScriptの仕様が、
シナジーにより「情報セキュリティに対する不備」を成していると言う事でしょ？
確かに突っ込みの余地はあるんだろうけど、分からなかったわけじゃなかろうに、
「何？」等ととぼけずに、本文の不足として補足してやれよ。
「良いトレードオフだ」とのことだ。 (スコア:0)
良いトレードオフってのは、作り手じゃなく受け手（マーケットかユーザか）が決めるものなんだけどね。
世に蔓延るのは、たいてい技術的に筋が悪いものの方だよね。なんていう法則だったっけ？
Re: (スコア:0)
でも、作り手も何らかのトレードオフをしないと世に出せないからね。
作り手から見た「良いトレードオフ」ってのはあるはず。それが受け手から見ても「良いトレードオフ」になるとは限らないけど。
Re: (スコア:0)
その受け手も問題だからね。
こういう履歴収集系のCSSを使っている場合、利用者ってのはブラウザのユーザーなのか、ウェブサイトを作っている側なのか…。
一番大きなデメリットは、「色以外変えられなくなる」って部分だけど、この点が嫌だと思う人はどれくらいいるのかな。
Re: (スコア:0)
色だとサイトによってまちまちなので、
:visited:after{content:xxx} を stylesheet で 当ててます。
禁止になるのかぁ
Re: 「良いトレードオフだ」とのことだ。 (スコア:1)
!important 指定を付けたユーザーサイドスタイルシートなら、さすがに無視しないと思いたいところですが……。
この辺りは主にアクセシビリティの点からの問題で、まさに「サイトによって色がまちまち」で、その結果閲覧者自身が判別できない色になることを防ぐために存在するものですし。
適用順序としてはブラウザのデフォルトスタイルシート → ユーザースタイルシート → サイトスタイルシート → サイトスタイルシート !important → ユーザースタイルシート !important であり、Mozilla 側で手を入れるのはサイトスタイルシート !important までにしないと、極めて筋の悪い実装となるでしょうね。
結局 (スコア:0)
JavaScriptで文字の色を読み取ればわかっちゃうんじゃないの？
色も読み取れなくなるとは思えないし
Re:結局 (スコア:1)
「JavaScript で取得できるスタイルを制限する」
色を読み取れなくするということでは？
Re:結局 (スコア:2, 参考になる)
これで (スコア:0)
サイトを跨いで履歴収集できるのはビーコン型アクセス解析の会社だけ。
誰得？
Re: (スコア:0)
>誰得？
google等
Re: (スコア:0)
Re: (スコア:0, オフトピック)
修正しました。ご指摘 thx。
# Emacs からコピペしてるせいか。
Hiroki (REO) Kashiwazaki
Re: (スコア:0)
どんな違法行為の責任？