Webブラウザの閲覧履歴や閲覧中のサイトのソースコードを盗む新手法 29
よく考えたなぁ…… 部門より
これまで、多くのセキュリティ研究者たちがJavaScriptやIFRAMEの抱える弱点と問題点について警告を行ってきた。今回、英国の研究者Paul Stone氏が新たに発見した問題はこれまで以上に深刻な内容であるようだ。発見されたのはJavaScriptを利用して、指定したURLを過去に訪れているかどうかや、そのWebブラウザで閲覧してるサイトのソースコードを読み取ることができる技術だという（threatpost、本家/.）。
攻撃者はユーザーがログインしている任意のWebページ上のソースコードへのアクセスを取得でき、ユーザーIDや個人情報などすべての種類の機密情報を取得できる。Paul Stone氏によれば、この問題を防ぐための簡単な修正手段は今のところないという。
threatpostの記事によると、Stone氏が発見した問題点は2つあり、1つは「すでに訪問したURLへのハイパーリンクは、未訪問のURLへのハイパーリンクよりもその描画速度が遅くなる」という点。これを利用し、ハイパーリンクを描画するのに必要な時間を計測することでそのURLにユーザーが過去訪れているかを判別できるという。
もう1つは「SVGフィルタを利用することで、Webブラウザウィンドウ内で指定した位置にあるピクセルの色を取得できる」というもの。これを利用することで、指定したIFRAME内の全ピクセル情報を取得できるという。これとページのソースを表示される「view-source」プロトコルを組み合わせることで、ユーザーのIDや個人情報などが含まれる可能性がある任意のページのソースコードを取得できるという。
1つめの問題は、Webブラウザの動作原理に由来するものなので対処が非常に難しいという。また、2つめの問題はFirefoxでは修正されているが、Chromeでは修正されていないとのこと。
抜け道? (スコア:2)
Firefox では Bug 147777 [mozilla.org] で対応済みのはずの問題ですが、今更話題になるということは、何か抜け道があったということでしょうか。時間計測攻撃は最初から、 SVG filter を使う話はたぶん 2008 年に出ています。どっちも 2010 年の時点で対応済みのはずなのですが。
Re: (スコア:0)
それはCSSの色設定を取得する手法で、今回のは、描画時間を計測する手法とのことで、異なる手法を用いていることになりますが、CSS問題のときに、今回の問題も対応されているはずだということでしょうか。
Re: (スコア:0)
リンク色についても(描画時間に違いが出る可能性のある)透明度の変更は認めないなど、タイミング攻撃対策は行なっていないわけではないのですが、履歴へのアクセス時間の差異はかなりどうしようもない感じがしますね。
Re:抜け道? (スコア:4, 参考になる)
ってか当のバグに「タイミング攻撃問題は未解決だよ」って書いてあった。
https://bugzilla.mozilla.org/show_bug.cgi?id=147777#c294 [mozilla.org]
関連してそうなバグが未解決なことからも解決の困難さがうかがえる。
https://bugzilla.mozilla.org/show_bug.cgi?id=557579 [mozilla.org]
https://bugzilla.mozilla.org/show_bug.cgi?id=557655 [mozilla.org]
Re:抜け道? (スコア:2)
知りませんでした。情報ありがとうございます。
Re: (スコア:0)
ランダムに遅延入れても人間相手なので問題無いとおもいますが、そんな単純な事じゃないっていうことでしょうか？
Re: (スコア:0)
> 人間相手
JavaScriptで機械的に計測してるんじゃないの?
コンマ数秒リンクの反応が遅れただけで○○$の収入の減少に直結するとかamazonもGoogleも研究結果出してるし、ブラウザはものすごいスピード競争してるってのに人間相手でも現実的な対策とは思えない。
速度が変えられないなら、時間の方を変えればいい (スコア:0)
Javascriptで取得できる時間の方を（秒未満だけ）
ランダムに進むようにすればいいんじゃないか？
Re: (スコア:0)
アホか、悪影響の方が大きすぎるわ。
むしろ最近ナノ秒単位で取得できるようになったってのに、時間をナメすぎ。
Re: (スコア:0)
単純にランダムな遅延を入れただけでは、多数のデータの統計を取ると、結局ノイズから信号が浮かび上がってきますよ。
もちろん困難さは増加するので、ちょっとした緩和策としてはいいのですが。
Re: (スコア:0)
パスワードクラックの古典的手法で同じ（反応時間の差で正解の文字
を求める）のがあったけど、それの対策するのにアセンブラレベルで処理数
同じにする必要とかあったからなあ。
Re: (スコア:0)
SSLでもあった。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0169 [mitre.org]
Re: (スコア:0)
近年の CPU では高速化のためのテクノロジのせいでステップ数が同じでも実行時間に差がでたりしそうですね…
BCASも (スコア:0)
BCASのカードがクラックされる原因になったのもこれ。
東芝か松下かどっちかのカードについて、パスワードに対する応答時間が入力文字列依存で変わってしまう事象があったことを応用して解析した模様.....。
Re: (スコア:0)
とりあえず layout.css.visited_links_enabled を false にして訪問済みリンクは Link Status Redux [mozilla.org] のようなアドオンを使うという回避策はこの手法にも有効なはず。
cookyも違法になるのか (スコア:1)
＃履歴自体を残さないのが初期設定になる日が来るのか
Re: (スコア:0)
cookyがcookieだとしても、関連性がよくわからない
Re:cookyも違法になるのか (スコア:2)
cooky読めってことでしょう
Re: (スコア:0)
こっけいですね。
iframe... (スコア:0)
iframeは百害あって一利なしなんだが、なんでこれ無くならないの？
「iframeあってよかったー！」って思ったことなんて全く無いんだけど…
誰が望んでるんだ？このタグの存在
Re:iframe... (スコア:1)
YouTube の Share -> Embed で出てくる動画埋め込み用タグを使う人たちかな
Re:iframe... (スコア:1)
他のレスにあるが、iframeでないと実現困難なことも多い。
もともとiframeはセキュリティを守りつつ他のページを埋め込むものだし。
Re: (スコア:0)
いまだにiframeでトップページを2分割してるサイトが沢山ある以上
必要
1x1pxとか明らかに不正利用のサイズを無視できる機能を作ればいいんじゃない
Re: (スコア:0)
そんなの明らかに不正かどうか分かんないし、意味なし。
Visibleで大きさ十分にあっても、他の要素の後ろに隠すとか、透明度高めにするとかいくらでも手はあるわけで。
むしろ見えないiframeは効果的に使われてるから、そんなのブロックしたらWebが壊れる。
Re: (スコア:0)
はてブボタンもlikeボタンもツイートボタンも、みんなiframe使ってますよ。
Re: (スコア:0)
どれもいらないものだw
Re:iframe... (スコア:1)
ンじゃ、いる物の典型例としてxvideoとかfc2とか挙げればいいかい？ｗ
// 上記三つが要らないものだ、って意見には同意せざるを得ないけどな
Re:iframe... (スコア:1)
くそっ…必要じゃないか…
Re: (スコア:0)