アカウント名:
パスワード:
user_pref("capability.policy.default.HTMLAnchorElement.focus", "noAccess"); user_pref("capability.policy.default.HTMLButtonElement.focus", "noAccess"); user_pref("capability.policy.default.HTMLButtonElement.click", "noAccess"); user_pref("capability.policy.default.HTMLInputElement.focus", "noAccess"); user_pref("capability.policy.default.HTMLInputElement.select", "noAccess"); user_pref("capability.policy.default.HTMLInputElement.click", "noAccess"); user_pref("capability.policy.default.HTMLSelectElement.focus", "noAccess"); user_pref("capability.policy.default.HTMLTextAreaElement.focus", "noAccess"); user_pref("capability.policy.default.HTMLTextAreaElement.select", "noAccess"); user_pref("capability.policy.default.Window.focus", "noAccess");
(#641240) by Anonymous Coward: 本題ですが、ソース見ましたか？ 「わざと」 マウスカーソルを置いて大体６秒後に開くようにしているだけです。 ダイアログがsecuniaのサイトに埋め込まれている事を、 同じアンカーで単体チェック出来るようにしているのだと思います。 肝は、リンク元タブのページから別タブに画面が遷移してるのに リンク元に埋め込まれたポップアップが一番上に開けてしまう点で、 ここでは、強引に新規ウインドウに開かないように「敢えてしている」 だけなので、悪意さえあれば誘導は全く容易いかと思います。
それにしても、Mozilla Projectの対応は早いですね。
細かいようだけど、Bug 124750 [mozilla.org]の報告は2002/2/10で、80を越えるdupを数え、尚且つ仮パッチ作成は2004/9/27です。単にタイミングがよかっただけではないでしょうか。現在のが仮パッチというのも加味しないと (trunkには入ってない)。
つまりFx 1.0 (Gecko/1.7) はいいけど1.1 (Gecko/1.8) はどうなるか、と。半年は先のことを心配しても仕方ないんだけどね…。
それは兎も角、 document.createEventを用いた問題 (Bug 265456) [mozilla.org]が残ってました。Fxは明日 (2004-10-23) 付けのビルドで、とりあえず両方とも問題なくなるようです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
試してみた (スコア:3, 参考になる)
DonutRAPT/Firefoxで影響が確認できた。
しかし新しいタブをアクティブにする設定にはしてないからいまいちインパクトに欠ける。
http://secunia.com/multiple_browsers_form_field_focus_test/
同じくDonutRAPT/Firefoxで影響が確認できた。
Citibankのページで入力したはずの文字がどこかへ消えるので妖しさ抜群。
おまけ：FirefoxならどうしてもJavaScriptを有効にしなければ
ならない時の為に以下の内容をprefs.jsに書いておくといいかも。
focus乗っ取り攻撃への一定の(完全かは知らん)防御効果がある。
Opera7.54/Win でも試してみた (スコア:3, 参考になる)
http://secunia.com/multiple_browsers_dialog_box_spoofing_test/
Opera7.54/Winで影響を確認．
ただし，リンクの上にマウスカーソルを置くだけでダイアログが開いてしまうので，うまく誘導しないとすぐにバレそうだ（他のブラウザでは，リンクを開くまでダイアログが開かないのかな？）．誘導に成功して，さらに新しいタブをアクティブにする設定にしていれば，CitiBankのダイアログと見間違えることは十分ありえる．
http://secunia.com/multiple_browsers_form_field_focus_test/
Secuniaのサイトにもあるように，Opera7.54/Winでは全く何も起こらない．
_.. ._._._ _... ._._._ ._. ._._._
物は試しだ。コメントのしきい値を2にしてごらん
Re:Opera7.53Ja(Build 3864)で試した (スコア:1, 参考になる)
としてダウンロード公開させているバージョンなんでしょうか…
（公開後すぐに落としたものなので）今回の問題はともかく、
他の修正が本当に適用されているのかやや不安ですけど。
何の注意書きも無いので、ライブドアが保証してくれるのかなー
って事で試した所、現象を確認できました。
本題ですが、ソース見ましたか？
「わざと」
マウスカーソルを置いて大体６秒後に開くようにしているだけです。
ダイアログがsecuniaのサイトに埋め込まれている事を、
同じアンカーで単体チェック出来るようにしているのだと思います。
肝は、リンク元タブのページから別タブに画面が遷移してるのに
リンク元に埋め込まれたポップアップが一番上に開けてしまう点で、
ここでは、強引に新規ウインドウに開かないように「敢えてしている」
だけなので、悪意さえあれば誘導は全く容易いかと思います。
＃もし、この7.53と今の7.53が違う物だとしたら、どうやって
区別をつけたらいいのだろうｗ
Re: Opera7.53Ja(Build 3864)で試した (スコア:1)
アドバイスありがとうございます．どのブラウザでも，「マウスカーソルを置いて大体６秒後に開く」と言う風に動作するのですね．
こちらのテスト環境はOpera7.54(Build 3869)にopera7.50-unofficial-japanese.lngを適用したものです．（ビルドナンバーが違うのがちょっと不安ですね...）
さて，本題ですが，
この脆弱性は「非アクティブなタブに埋め込まれたJavaScriptも（アクティブなタブと共通の）ウィンドウの上にダイアログを開くことができるということを利用して，ダイアログがアクティブなタブに埋め込まれたJavaScriptが開いたものであるかのように勘違いさせることができる」というものですが，これは「マウスカーソルを置いて大体ｎ秒後に開く」という形以外でも実現可能なものなのでしょうか？
つまり，secunia.com のテストコードでは setTimeout を使って6秒後にダイアログを開くようにしていたのですが，この部分はこの脆弱性に対する攻撃において必須ではなく，例えば，「フィッシングを行おうとしているサイトのタブが非アクティブになってから数秒後にダイアログを開く」といったようなより見破りにくい攻撃が可能だったりするのでしょうか？
SA12713 [secunia.com]では説明されていないこの点について，何かご存知でしたら教えてください．
_.. ._._._ _... ._._._ ._. ._._._
物は試しだ。コメントのしきい値を2にしてごらん
Re: Opera7.53Ja(Build 3864)で試した (スコア:1, 興味深い)
>といったようなより見破りにくい攻撃が可能
僭越ながら、それは逆に見破りやすいと思いますね。
そのような、ユーザーの操作と無関係に時間差を利用して詐欺を
働く価値のある情報を入れさせるには、言葉巧みかどうかだけですね。
詐欺に引っ掛かるのは、甘い話に乗りたがる心理が働くとか、
物事の分別がつかない人間が引っ掛かると言えば、それまでな気もしますが。
プロンプトに「カードの暗証ナンバーを入れてください ”○×銀行”」
など入ってるかどうかで、安易に信頼してしまう人もいるかと思う。
（巷で聞くフィッシング詐欺の手口に乗るような人ならば）
SA12713で説明されていないのは、JavaScriptで新しく開いたウインドウを
アクティブにするのは説明するまでも無く可能だからでしょう。
画面遷移と同時に暗証ナンバーを求められたほうが怪しくない？
って見方もあるかと思いますが、サンプルのようなトップページではなく
実際のキャンペーンページを開いて、それを知らせるための善意であるような
誘い方をすればよいのでしょう。
フィッシング詐欺の、そういった最初の誘い込みに引っ掛かるのが
個人的には信じられないのですけどね。
Re:試してみた (スコア:1)
それにしても、Mozilla Projectの対応は早いですね。
Super Souya
Re:試してみた (スコア:2, 参考になる)
細かいようだけど、Bug 124750 [mozilla.org]の報告は2002/2/10で、80を越えるdupを数え、尚且つ仮パッチ作成は2004/9/27です。単にタイミングがよかっただけではないでしょうか。現在のが仮パッチというのも加味しないと (trunkには入ってない)。
つまりFx 1.0 (Gecko/1.7) はいいけど1.1 (Gecko/1.8) はどうなるか、と。半年は先のことを心配しても仕方ないんだけどね…。
それは兎も角、 document.createEventを用いた問題 (Bug 265456) [mozilla.org]が残ってました。Fxは明日 (2004-10-23) 付けのビルドで、とりあえず両方とも問題なくなるようです。
Re:試してみた (スコア:0)
http://madchester.s54.xrea.com/bbs/8631.html
＞しかし新しいタブをアクティブにする設定にはしてないからいまいちインパクトに欠ける。
同感です。かなり特異な状況が重なった場合しか騙されないのでは？
これは脆弱性というより、タブとJavascriptの仕