Webブラウザにダイアログ“詐称の脆弱性あり”との主張 49
ストーリー by Acanthopanax
転ばぬ先の杖か、杞憂か 部門より
転ばぬ先の杖か、杞憂か 部門より
mew 曰く、 "Secuniaのアドバイサリで、複数のWebブラウザに「ダイアログボックスの提供元を詐称できる脆弱性」があるとの主張が公開された。Javascriptを用いてダイアログボックスを表示するとき、多くのWebブラウザでは、通常ダイアログボックス自身にまでは「それがどのサイトから提供されたか(どのようなサイトがそのダイアログボックスを表示したか)」は示されない。このような実装を悪用すると、あたかも信頼できるサイトから提供されているかのようなダイアログボックスを表示することができてしまうのだ、という。Secuniaによる実証ページも用意されている。
現時点で、以下のブラウザについてのアドバイサリが公開されている。
- Safari 1.x
- iCab 2.x
- Opera 7.x, 8.x
- Mozilla 1.7.x / Firefox 0.x, 1.x / Camino 0.x
- MSIE 6.x (5.x以下は不明)
- MSIE 5.x for Mac
対策は「信頼できるサイトを閲覧しながら(別ウィンドウで)信頼できないサイトを閲覧しないようにすること」。Javascriptに起因する問題なので、Javascriptなどの無効化でも良いと思われる。Secuniaによる重要度は5段階で下から2番目のless criticalとされている。なお、ITmediaに関連記事が出ている。Opera 8.01では対応されているとのことだ。
脆弱性と言われれば確かにその通りなのだが、いささか偏執狂気味にも思えるこの主張を、皆様はどうお考えになりますか。"
これに限ったわけじゃないんですけど、 (スコア:3, すばらしい洞察)
この主張は杞憂に思えるかもしれないんだけど、
このアドバイザリを目にしないような層には脆弱性足りえるような気がします。
そういった人達にどう意識してもらうかってのは重要な気がするけど、
一般マスコミがこういった事いうと妙にピンと外れだったり、
逆に外れてないような事書くマスコミは一般じゃなかったりで
難しいことっすね
このデモだと危険性が分からないかも (スコア:3, すばらしい洞察)
スパイウェアに感染した時に見かけたが、これよりも、ページそれ自体がダイアログを真似てる方がひっかかる可能性は高いように思う。タブブラウザだとひっかかる人は少なそうだけど。
というか、タブブラウザ以前に、数ミリ程度の小型のウィンドゥサイズで常駐して悪さをさせる手口ってのはよく見かけたけど、それと同じじゃないのか?、なんか今更という気がすんだが?
Re:このデモだと危険性が分からないかも (スコア:1)
私のところでは,本物のサイトの上に空白ウィンドウが小さく出て,空白ウィンドウの上にダイアログが巧い具合に重なりました.
結果,空白ウィンドウは見えなくて,本物のサイトの上にダイアログが表示されたように見えます.
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
# どの設定?
Re:このデモだと危険性が分からないかも (スコア:1)
ほとんどの場合で、タグとして開くように設定してるんで、その空白のウィンドゥが確認できてるんだと思う。
#シングルウィンドゥモードを有効にするだけでも良いとは思いますけど。
Re:このデモだと危険性が分からないかも (スコア:0)
ダイアログボックスがでて、キャンセルするとGoogleに飛びました。
(passowrdと打ち込んでも、挙動はほぼ同じでした)
タブに関する設定では
browser.link.open_external = 3
browser.link.open_newwindow = 3
を変更しています。
Webブラウザ限定ではない (スコア:3, 興味深い)
少しばかり言い替えると、
「信頼できないサイトを閲覧」と「信頼できないアプリケーションを実行」には大きな差があるので、同列には考えられないですけど。
そもそも (スコア:2, すばらしい洞察)
ほとんどのケースで使う必然性が感じられず、むしろうっとおしい。
Re:そもそも (スコア:0)
やってみてわかったけど、パスワードをダイアログで
入力させるサイトが世の中に少なければ、
(現実にも多くないと思うけど)
このような偽ダイアログ表示によるフィッシングの
効果は減少するし(「ん?何でダイアログが..」
とう違和感をもつことが注意をはらうきっかけになる)、
サイトを作る側としては、必然性なしのダイアログを
使わないことが、この種の騙しの有効性を
Re:そもそも (スコア:0)
「うっとおしい」には反対というか疑問。
「鬱陶しい」の読みは「うっとうしい」。
Re:そもそも (スコア:0)
おもわず「うっ」と漏らしてしまうような些細な欠陥が気になって、
「こうだったらもっとよかっただろうに」と惜しむ様。
新曲解酷語辞典より
#つまらないのでAC
Re:そもそも (スコア:0)
どうしてもやりたいなら、それこそチラシの裏かご自分のブログででもやってください。
同意 (スコア:0)
ソフト固有の脆弱性というよりも (スコア:2, すばらしい洞察)
既存概念とかそういったものからくる脆弱性ですね。
そもそも脆弱性と言っていいものかも難しいと思いますが…。
少なくともソフトウェア固有の問題ではないとおもいます。
Re:ソフト固有の脆弱性というよりも (スコア:0)
小奇麗にしようとするから無理が出る。
もっと文字情報を前面に押し出すUI仕様に先祖帰りしよう。(いやまじで)
Re:ソフト固有の脆弱性というよりも (スコア:0)
Re:ソフト固有の脆弱性というよりも (スコア:0)
文字に限らず、表示情報って増えていってある一定量を超えると
今度はすべての表示情報を見てくれなくなっちゃうんだよね。
(何を書いてもまったく
Re:ソフト固有の脆弱性というよりも (スコア:0)
JavaScriptに限らず文字情報を下働きにするのは良いけど何処かで流し見れる形に出来んのかな。(クリックとか余分な操作無しに)
ステータスバー(こ
GUIがまだ足らない。 (スコア:0)
金持ってる所のUIデザイナーが出してくれるマシなアイデアに期待します。
Mac OS X のシート (スコア:1)
Mac OS X から導入された「シート」は、最適ではないでしょうか?
ウィンドウのタイトルバー付近から垂幕のごとくダイアログが降りてくるというインターフェースです。ウィンドウとダイアログがくっついているので、両者が関係あるのが一目瞭然です。
ただ、このインターフェースが、Mac OS X における独自のものだと Apple が主張すると、他の OS で導入しにくくなりますね……。
Re:Mac OS X のシート (スコア:1)
ダイアログの度に空白のウィンドゥがアクティブになるのは、疑ってくれと宣言しているようなものだと思う。
アクティブにならずに表の本物のウィンドゥにダイアログが出せるんなら、だまされる人も出そうだけど。
Re:Mac OS X のシート (スコア:1)
Mac 版の FireFox でもデモを試してみましたが、 JavaScript ダイアログがシートで表示されました。小さい空白ウィンドウからダイアログがにゅるっと出てきました。
Linux 版の FireFox は使ったことがないので分かりませんが、おそらくシートダイアログを採用しているんでしょう。これでは、騙されにくくて安全かもしれません。ちなみに、Windows 版 FireFox はシートになりませんでした。
>アクティブにならずに表の本物のウィンドゥにダイアログが出せるんなら、だまされる人も出そうだけど。
それができてしまうと、本当に脆弱性と言えると思いますよ。
Re:Mac OS X のシート (スコア:1)
Linuxの場合もWindowsの場合も同じくダイアログです。
ただ、同じくアクティブになった空白ウィンドゥに依存している点は同じということで。で、これがタブブラウザだと、画面全体が空白になるので、ひっかかる人は少ないだろうなというだけのこと。
Re:Mac OS X のシート (スコア:1)
>Linuxの場合もWindowsの場合も同じくダイアログです。
なんだ。そうなのですか。親コメントでは、
>>Fedora CoreでFirefox使っているが、件のデモだと、そのシートとやらと、ダイアログは同じような挙動してるんですが?
と書いてあったので、てっきり「Linux 版 FireFox はシートみたいな挙動 (ダイアログがにゅるっと降りてくる) をするのだと読んでしまいました。
ということは、ダイアログは一瞬でパッと表示されるものの、親となるウィンドウを隠さずに、タイトルバーのすぐ下に出るということでしょうか。
# 言葉で動作を書くのはむずかしい……。
Windows 版 FireFox だと JavaScript ダイアログが親ウィンドウを隠してしまっています。これは騙されそうです。
>で、これがタブブラウザだと、画面全体が空白になるので、
NewWindows() もタブで表示させる設定だと、そうなりますね。NewWinodw() は新規ウィンドウにする設定だと騙されてしまいそうです。
Re:Mac OS X のシート (スコア:1)
「ウィンドウとダイアログがくっついている」ってのは
凄く大事なポイントっぽいですね。
最近思うんだけどさ、いまどきのGUIの「問題」の幾つかは、
○ウインドウを入れ子にする
ことによって、
解決しちまうんじゃなかろうか?
ウインドウとダイアログの関係もそう。
デスクトップじゃなく1つのウインドウの「中」に
ダイアログが出て、出てる間は下の(対応する)ウインドウのフォーカスを奪う、
という風にしておけば、それでいいわけで。
Windowsには(だったかな)MDIっていう入れ子窓みたいなのがあるが、
あれって親子関係は一段だけだし、
親は子を入れる枠として専用化されちゃうしで、
自由度低すぎ。
あれを
○多段の入れ子もアリ
○親も子も、専用化はしない。枠でも中身でも好きに表示しろ。
(これは制約を設けないだけだから、処理や構造はべつに複雑にならないはず)
○(何かの役に立つだろうから)入れ子関係を、生成後に変更することができるようにする。
(これでSqueakに手が届く…か?)
○上記のようなフォーカス奪い(それをDialogと称する)とか、透明化(Dashboardっすか(藁))とか、そういう仕組みも入れとく。
○いわゆるデスクトップ自体も、単に「ルートの窓」として定義(?)する。
ってな風にすると、大した仕組みを組み込まなくても、
結構色々使える(&安全になる)んじゃないか?と思ってる。
ついでに、
○フォルダと、GUI描画(?)領域とを、同一視する。
○○X画面飛ばしと、NFSとが、同一視できる(ぉぃぉぃ
○ファイルとオブジェクトも同一視する
○○フォルダにボタンObjectを置いてフォルダを表示すれば、ボタン1つが載っているアプリの出来上がり。
○(別んとこでも書いたけど)メニューとフォルダ(と描画領域)も同一視。
○○フォルダにボタンを置いて左上隅に小さく表示(藁)すれば、それがメニュー。
○ファイル(特に実行ファイル)とプロセスを同一視つーか「同じ構造」とみなす。
○○ファイルをClone(PrototypeOOP用語)するとProcessだ。
○プロセスがGUI描画領域を持つということは、プロセス「が」フォルダを持つということ。
なんてのもどうかなーと。
(やばい。そろそろ非セキュアになってきたなあ)
Re:Mac OS X のシート (スコア:1)
これ↑はちょっと自信がないんですが、
(略)これってモロに今の X Window System なのではないですか? 例えば、X でのスクロールバーとかメニューとかボタンって大抵 Window ですけど...
どちらかというと
以降の方が面白そうです。 :-)
# 実用に耐え得るかどうかは別で、
# あくまでアイディア実験として。
# というか、既にどこかの砂場でやられてそうな気がしますけど。
Re:Mac OS X のシート (スコア:1)
ええ。APIレベルではそうなんです。
Windowsでもそうですね。全部WindowHandleという概念で統一されてる。
が、ユーザ(UI)レベルから見れば、
各Widgetは各Widgetとして特殊化されてて
それらの共通性はむしろ隠蔽されてます。
WindowHandleみたいな概念はただの Widget実装の道具として
(つまりプログラマによって)使われてるだけ。
その自由度をユーザレベルにも開放(?)したいんです。
具体的には例えば、
「○多段の入れ子もアリ」
ってのが実際に実装されてるのって、あまり見かけません。
Windowsだと、よく知らないけどMFCの教科書とかにはMDIが必ず出てくるんで、
たぶんMFCがMDIという非多段窓をプッシュしてるんだろうと思います。
で、ゲンジツを見ると、そのアプリを作ったライブラリがMFCであろうがなかろうが、
MDIを採用してるアプリって、凄く多い。
(みんな洗脳されてるんだろなあ)
そしてXとかでも、MDIっぽいUIはしばしば見かけますが、
幾らでも入れ子をしよう!っていう発想で作られたUIは
あまり見かけません。
(こちらもみんな洗脳されてるんだろなあ)
これが俺としては残念なんです。
そんなわけで、俺が(ここで)言いたいWindowとは
APIレベルの話じゃなく、
世間でFormとかDialogとか呼ばれてる、いわゆる「窓」(ん?)です。
あれを、「○多段の入れ子もアリ」とかにしたいんです。
ちなみにDashboardネタを見てるうち [srad.jp]に思ったことだったりもします。
つまりDashboardとは、
Desktopという窓に、 Dashboardという窓(透明)を、
オーバーラップさせたものだ、と捉えればOKなんです。
(俺の理解が間違ってなければね:以下同文)
DashboardがVisibleかどうかはF12で切り替わる、と。
そして前述の通り、Dashboard窓にWidget(X用語じゃなくDashboard用語のほうの)窓を置ける、と。
で、
DashboardとかWidgetとかいう「特別な」ものをOSメーカが用意するよりも、
上記のように単純で(ユーザの手により)応用可能な仕組みが用意されてるほうが
いいんじゃないかなーと思ったんです。
例えばこの例だと、WidgetをDashboard(という名の窓)かDesktopか、
どっちに属しているか?をユーザがささっと変更できれば、便利なわけだし。
だいいちDashboardみたいなもの「を」ユーザが簡単に自作できるほうが、便利なわけだし。
だって、上記のようにすれば、単に「透明窓を用意する」「それをF12で出させる」だけで
できあがっちゃうんだもん…
#そして、パクリだと訴えられませんようにと祈るわけです(わら
あと垂幕云々もそうですし。
というか今まで「ダイアログ」を独立した別窓[*]で出すというUIを採用してたのが間違っていたわけで。
[*]独立といっても、上記の定義(?)より、真に独立した窓はRootであるDesktopしかありません。
ここでいう独立とは結局、そのダイアログを出すキッカケになった窓(か、その更に元となった「アプリ」の窓)に
従属していない、ということです。
>以降の方が面白そうです。
ああ。ファイルとかアイコンとかオブジェクトとかの話は
前半の「窓」の話だけの話よりも、さらに広い話をしてますから。
オブジェクトの中にオブジェクト(たとえばディレクトリにファイル)を置くのは、すなわち
それ(のデフォルトビュー)のWidgetに入れ子関係を持たせるのと、等価だと見なしたい。
個人的には、MVCよりも、Mに「デフォルトビュー」が必ず1つついてるという方式のほうが、
判りやすいんじゃなかろうか?と思っています。
ほっといてもとりあえずデフォルトのビューは提供される、という世界です。
>既にどこかの砂場でやられてそうな気がしますけど。
そりゃそうでしょうね。
こんな単純なアイデアが既出じゃないとしたら、
俺は人類の未来に絶望せんとなりません(^^;
実際にやってみた (スコア:1, 参考になる)
デモやってみると、あー確かにだまされる人いるかもと思う。
それに、Konquerorはちゃんと「それがどのサイトから提供されたか」を表示してくれた(からアドバイザリがないんだろう)けど、多分普通の人は慌てちゃってそこ見ないぜ。
要するに、フィッシング詐欺じゃないか。
信用問題 (スコア:1)
信用出来るサイトと信用できないサイトが表示されたとして、
それがどうしたって感じですが。
Re:信用問題 (スコア:1)
#これってFirefoxだけの挙動?
Re:信用問題 (スコア:0)
最近、信用できない入力formが多いらしいので、すくなくとも一回目は必ず間違ったIDやPASSWDを入力する癖がついたのですが、これで安全でしょうか? これで相手はだまされてくれるでしょうか。
Re:信用問題 (スコア:0)
これ [slashdot.jp]を読んでみましょう
Re:信用問題 (スコア:0)
うむむ、ご指摘の高木さんのページは読んだことがあるような気がします。うっかりしてました。過去のログインがどこから行われ、どのように間違えたかなど、記録がホストで読めるようになっていると、少しは安心かな。事後的なものですが。
IEの脆弱性ならこき下ろすくせにな、 (スコア:0)
IEに脆弱性報告をしてみろ
Re:信用問題 (スコア:0)
それはクリアされる人もいるでしょう。そこで、重要な情報を疑いなく入力しちゃうのは
この脆弱性には関係ないユーザ自身の問題ともいえるけど。
まあ、それを言い出すと全てのブラウザは、信用できないサイトにいかなければいい
何があろうがインターネットは自己責任って事でパッチの必要なしか。
少なくとも、偏執すぎやしないかなんてタレコミみた
Re:信用問題 (スコア:0)
その時点で人間の脆弱性じゃね?
責任云々ではなく、原因の所在を見誤ると実効的な対策は打てない。
Re:信用問題 (スコア:1)
Re:信用問題 (スコア:0)
機械をだまして「私は本物ですよ」と提示することで、機械を信用する人をだますのは簡単でしょうし。
Re:信用問題 (スコア:1)
だます方法が異なるだけの問題では?
セキュリティ対策とは (スコア:1)
案件を「偏執狂」とレッテル貼りすることであたかも対応する側も偏執狂であるかのような指摘をすることは、意識が低いと思います。
個人の PC であれば「リスクを承知した上で対応しない」という選択肢もアリかとは思います、何か起きれば自業自得だし。
ただ、リスク評価をできない人や、組織で使っている(又は他人の) PC にも責任を負う立場であれば、そうもいかないでしょう。
なので、危険性が低いとされるようなアドバイザリでも、十分に有意義だと思います。
# 危険性評価の結果、セキュリティレスポンスチームのリソース不足等から対応を後回しにするのは、運用上ありうることだとは思いますが。
この話題? (スコア:0)
Re:この話題? (スコア:1)
前回の「Multiple Browsers Dialog Box Spoofing」は現在見ているページの背後にあるタブからpromptを呼ぶもので、タブ・ブラウザーでないとできません。呼び出し元をウィンドウ単位で前面に出す仕様を逆手に取ったものです。
これは、呼び出しているタブを前面に出すことで「どのページから呼ばれているか」を明確にすることができます。
今回の「Multiple Browsers Dialog Origin Vulnerability」は、ダイアログボックスに隠れる位置に小さなウィンドウを開き、その中から呼び出すものです。呼び出し元は前面になっているのに隠れていて見えないので、背後にあるページから呼び出されたように見える、というものです。
偏執狂でいいんじゃない? (スコア:0)
ただ、重箱の隅だけつついてるだけじゃ駄目だけど。
Re:偏執狂でいいんじゃない? (スコア:0)
いよいよ立ち行かなくなると、裏でクラッカーを使って恐怖をあおりまくるに違いない。
ダイアログ出されても (スコア:0)
(そういう類の表示された情報のうち脆弱性などにより偽装可能な物もあり過信はできないが)
パスワードとかのクリティカル情報を入力する時には、ユーザ自身が自己責任で注意する必要もある。
--
Licensed under GFDL.
Re:ダイアログ出されても (スコア:0)
ページではなくダイアログの方から出自が分からない(複数ページが表示されている場合)のが問題なのですが。
"less critical"としては妥当な指摘だと思います。
Operaの対応って (スコア:0)
やらないよりはマシってことかな……。
特に脆弱性というわけでもなく (スコア:0)
特にブラウザの脆弱性というわけでもなく。
ただ、公開日的には@ITの方が遅いから、今回の脆弱性の件を受けて追記した可能性も…(のようには見えませんが
Re:特に脆弱性というわけでもなく (スコア:1)
(というか、デモの方がはるかに稚拙)
@ITの手口は、タブブラウザの設定次第で見抜けると思いますけど?
1.xだけじゃなく (スコア:0)
でもOperaの対策と言っても参照元のURIを表示するだけなので
殆ど読まずに入力する人には意味がない