ユーザのクリックを乗っ取る「クリックジャック」 66
ストーリー by soara
これは痛い 部門より
これは痛い 部門より
あるAnonymous Coward 曰く、
ZDNet(日本語訳)にて、多くのブラウザやAdobe Flashに存在するクリックジャック(Clickjacking)に対する脆弱性について報じられている(本家/.より)。この脆弱性はIE、Firefox、Safari、Operaなど多くブラウザやAdobe Flashに存在し、影響を受けないブラウザはLynxくらいだそうだ。
クリックジャックされると、ユーザのクリック全てがクリックジャックのクリックとなり、ユーザの意図や動作とは無関係にページ上のリンクやボタンをクリックしたことになってしまう。このため、Flashゲームなどは格好のターゲットとなり得る。攻撃はブラウザの根本的な欠陥を突いたもので、DHTMLを利用しているとのこと。また、JavaScriptは必須ではないため、JavaScriptを無効にしても完全には防げないそうだ。
クリックジャックはOWASP NYC AppSec 2008 ConferenceにてProof of Conceptとともに発表されるはずだったが、Adobeや他ベンダーからの要請により、発表はベンダーが対策を準備できるまで延期されたとのこと。
なお、ZDNetのアップデートにはNoScriptの製作者Giorgio MaoneがZDNetの記者にあてたメールが掲載されており、それによるとNoScriptのデフォルトコンフィグでは危険な攻撃の大部分を防げるとのこと。さらに、「プラグイン」設定の「IFRAMEの禁止」オプションをオンにすることで、攻撃を100%防げるとしている。
現時点ではまだ詳細が発表されていないため、続報が待たれるところだ。
CSS + Flash (スコア:5, 興味深い)
ただ、チキンなのでACで。
これは、CSSを使って、透過したFlashをウィンドウの全面に貼付けて、クリックを奪ってしまう、ってことなんだろう。
実際に実行コードも書いてみたけど、見事にちゃんと、記事のとおりになった。
(と、ここでかっこ良くサンプルページを貼付けたいんだけど、あまりにも単純すぎて、コピペでそのまま悪用できるのでやめた)
実際にスクリプトはFlashの中で動くので、JavaScriptが切ってあっても問題ない。
JavaScript をターゲットのページに投げるのは一筋縄ではいかないけど、Flashになれてる人なら簡単だろう。
逆に考えると、Flashの中で生成できるので、例えば現在のURLにパラメタを追加して投げるとか、そのページ内に存在しない何かをどこかに向かって投げるとかも簡単。
これを防ぐには、ユーザーレベルでは、Flashを切る or CSS を切るかどちらか。
Adobeが根本的に対応するには、Flashの背景(ステージ)の透過を出来ないようにするしか無い。
これはあまりにも簡単で、何でも出来て、ぱっと見バレにくいから、攻撃として流行りそうな気がする。
しかも、出ている情報だけでわかる人にはわかってしまう、一番中途半端で問題の多いパターンだと思う。
だから、詳しく書いてみた。
Re:CSS + Flash (スコア:3, 興味深い)
何か関係があるのかもしれません。
ただし Firefox では動作しなかったので、別件だとは思いますが...
こんなふうに <iframe> 要素全体を <a> で括ってやると、
iframe 内の任意の箇所(リンクは除く)をクリックすると <a> が動きます。
上記例では、iframe 内の google ページの適当なところをクリックすると、
スラドが開いてしまうというものです。
ウィンドウ全体に広がるような iframe を作成して、
アフィリエイト等のクリックさせたい URL に向けたリンクで囲ってやれば、
何か面白いことができそうだね、という話をしていたのですが...
Re:CSS + Flash (スコア:2, 興味深い)
そうだとすると透過を禁止するだけではなく、リンクのあるところでは必ずカーソルが変わる、という仕様が必要ではないですか。脱出系Flashゲームは専用のブラウザでやることに…?
Re:CSS + Flash (スコア:1, 興味深い)
延期されたのは発表じゃなくて (スコア:2, すばらしい洞察)
#この解釈で正しいのだとすると、記事自体がわかりにくいんだけれども…
Re:CSS + Flash (スコア:1, すばらしい洞察)
画面全体にぱらぱらと、なにかが落ちてきたりするFlash。
もちろん、どこかクリックしないとはじまらないというのが多い気がしますけど。
NoScript (スコア:1)
NoScriptのデフォルト設定はフツーに閲覧するには少々厳しすぎない?
私はNoScriptを入れてるけど、いつもは無効にしてる。
JSとCSSの住み分けが進む (スコア:5, 興味深い)
Javascriptを視覚エフェクトとしてつかっているサイトは非常に多いと思いますが、Scriptなしでも最低限の機能は提供するのがうまい設計であって、切るだけでボロ崩れ/飛べない場所が出る等の機能不全を起こすのはダメダメといえます。
CSS2.1(の主にセレクタ)をフルに使えるブラウザに最適化されたサイトは、この部分にさえ、Javascriptを多用する必要はありませんよね。
これから視覚エフェクトはCSS一本に、Javascriptはそれ以外にと住み分けが進んでいくと思います。
# Noscriptはホワイトリストで使ってますが、まともに見れなくなるダメサイト結構多い。
Re:JSとCSSの住み分けが進む (スコア:1)
画像使わないなんて事は上が許してくれないわけで・・・
そうなるとcssじゃ全然足らないよ・・・
Re:JSとCSSの住み分けが進む (スコア:1)
CSS の表現能力が足りないのではなく、ブラウザの CSS 実装レベルが足りないって方が現実に合っているかと思いますが。
画像を使うと CSS じゃ無理、なんてのはかなり意味不明です。
Re:JSとCSSの住み分けが進む (スコア:1)
アンカーがテキストだったらcssで「全部共通で」色を変更したり指定できる
アンカーが画像だったらどうする?
単純にimgタグを使う場合cssでは違う画像に変更するなんてできないよね
background-imageで指定してそれを切り替えるという手段もあるけど
その場合すべての画像を使ったアンカーに対してcssを書かないといけなくてとても面倒だしサイズが大きくなるよね
だからjs使ってmouseoverで画像切り替えるような処理にするのは当然の方向性だよね
Re:JSとCSSの住み分けが進む (スコア:1)
a 要素の内容に img 要素しか置かないならこれでできますけど。
URL 完全一致ではなく、前方一致でやりたいなら a[href^="..."] ですね。CSS3 Selectors になりますが、Gecko や WebKit 系なら普通に対応してます。CSS3 Selectors 的には :before ではなく ::before ですか。
後は元の HTML 側でリンク先ごとに個別の画像を a 要素の内容に置いておけばいいですね。
この程度の列挙でも面倒だけど JavaScript なら面倒じゃない、とはとても考えられないほど簡単なレベルだと思います。どうでしょうか。この書き方なら代替表示する画像も一括管理可能です。
そして、リンクがある HTML 文書が 1 つしかないのであればともかく、複数の HTML 文書から成立しているのであれば、この程度の記述の列挙程度は (どうせ CSS もキャッシュされるものですし) トータルサイズ自体はより小さく収まるでしょうね。
ただし IE6/7 は CSS2 以降への準拠度が激しく低いため、現実的に IE が想定される場面においてこれは使えません。元コメントでの意はその点を指しています。
全リンクを onload 時に拾って onmouseover イベントを個別に埋め込んでいくのはクライアント環境にとっては製作者側の負担を閲覧者側に押し付ける無駄な処理でしかありませんから、結局 JavaScript でも HTML に対して個別に onmousehover を設定する事にならないでしょうか。
CSS を使った方がサイト全体の HTML に対して埋め込み忘れがないかを気にせず書ける点で、管理コストを下げる面においても有利でしょう。
background-image でないと CSS で似たようなことができないというのは、IE が上のような記述を行っても動作しないからです。それは CSS だけではできない事ではなく Web ブラウザ側の問題です。
少なくともその程度の範囲であれば「IE がタコだからこの程度の事でも JavaScript じゃないとだめなんだよね」と言うのは納得できますが、「CSS がタコだから~」と言うのは CSS を分かってないだけとしか思えません。
Re:JSとCSSの住み分けが進む (スコア:1)
凄まじく面倒です
a:hover:before > img.chimg[src="(.*).(.*)"] { content: url($1_o.$2); }
適当に書いてみましたがこれくらいの1行で「サイト内すべて」の画像切り替えが実現できないと使えるとは言えない
Re:JSとCSSの住み分けが進む (スコア:1)
本気で言ってますよ。それでもサイト全体の全文書に JavaScript を埋め込むよりマシですから。CSS は on だけど JavaScript が off だと全く機能しないようなものよりはマシだし、ある程度量が増えたら make 一発生成とかして終わりになるだけでしょうから。
それと、正規表現的にあまりにもありえなさすぎる例示なのでエスパー解釈してみようと思いましたが、CSS でひたすら列挙する方がコスト的に少ない点と漏れが出る可能性が低い点、確認コストが少ない点などから確実にマシですね。HTML 側はサイト共通スタイルシートの指定以外何も文書をいじる必要がないのですから。
それと、img 要素の src にそんな単純な範囲で指定できるなら、そもそも class 指定すら不要に思えますね。
Re:JSとCSSの住み分けが進む (スコア:1)
まずサイズ
1行目の
a[href="http://www.example.com/"]:hover:before { content: url(http://www.example.com/images/top.png); }
が104文字
1つのリンクに対して約100byteとすると
リンクが10000あったらそれだけで1Mbyte
そんなサイズのcssは今のところ現実的ではないですね
列挙するコスト
静的ページならパースかければとりあえず漏れなく列挙できるでしょうね
でも動的ページならどうしますか?
「一発生成」できるようにするまでのコストがとんでもなくでかいと思いますよ
切り替えする画像としない画像の判定はどうしますか?
結局何かしらのキーワードがhtml側に埋め込まれないと現実的にはできないと思いますね
というかそんな面倒なことやるよりjsでやる方が遙かに低コスト
そもそも「ユーザの行動に対して画像を切り替える」事を実現するのにjsを使うのが間違いな訳がないよね
googleMapもおなじだもんね
それが「リンクにフォーカスしたら画像を切り替える」になったらjsを使うのが間違いっていうのは納得できないね
Re:JSとCSSの住み分けが進む (スコア:1)
そりゃあり得ないですよね。1 サイトで 10,000 も個別にリンク用画像を置き換える必要があるサイトとか。(笑)
そのために JavaScript を埋め込む製作者のコストと、個別のページの各リンクに埋め込むコストについてはどうですか? 単純にサイズ面でも ' onmouseover="a();"' (最短パターン) で 19 文字が増加する訳ですが、1 HTML 文書内に重複なしで 10,000 個のリンクがあったら、HTML ファイルが 10 個あるだけで 1,900,000 バイト増える事になりますね。
もちろん 1 HTML 文書内のリンク数が固定される状況ではない、つまりナビゲーション用のリンク等の固定的なものではなく、本文に含まれる部分でリンク画像置き換え (なんてする訳ないよね、普通) が行われる可能性があるとすると、置き換えが行われる可能性があるリンクのパターンは確かに 10,000 パターンあるかもしれないですが、リンクに対する onmouseover の埋め込みが必要な個所は数十万、数百万に上る可能性があるのですよね。
onload で対象のリンクに対し onmouseover ハンドラを設定していくなんて、可能性として最低でも document.getElementsByName('a'); で 1 万以上の要素が引っ掛かる可能性がある文書に対してなんて適用できない話ですし、そもそも文書ツリーに含まれる要素が非常に多い場合、getElementsByName() や getElementsByClassName() のコストは非常に高くなるため、あくまでも HTML に静的に埋め込むコストの方でお願いします。
1,000 個程度でも異常に多いレベルなのに、10,000 のパターンとか非現実的すぎますね。そんな数の置き換え画像をプリロードされたら、閲覧者にとっては地獄としか言いようがありません。
本気でそこまでやるようなプロデューサーがいたら正面きって批判してあげた方がその人の為でしょう。
URL の生成パターンすら決まってなくて、ドメイン名直下から常にリンク先 URL がランダム生成なのですか? それこそ非現実的すぎですね。
もっとも、ヒントとなるパラメータがあるなら a[href*="&mode=foo"] とか書けますけど。
前方一致/後方一致/部分一致/完全一致にスペース区切りのトークンに対する一致程度は属性セレクタで指定できますので、これで拾えないパターンの URL が生成される事の方が稀ではないでしょうか。
IE 等を考慮すると現実的な解としては結局 JavaScript になる、という点については全く否定していないのですが、何か勘違いしていませんか?
もう一度最初に書いたコメントを繰り返しておきますね。
Re:JSとCSSの住み分けが進む (スコア:1)
>画像を使うと CSS じゃ無理、なんてのはかなり意味不明です。
それぞれ個別に記述をしないといけないという段階でcssの表現能力が全然足りてない
a:hover で「一括で」フォーカスされたアンカーの見た目を変えれることは素晴らしい
img:hoverで同様に「一括で」画像を切り替える記述はできないよね
そもそも「画像を切り替える」ってことがcss的ではないといえるんだけど
img[src="http://example.com/img/link_button.png"]:hover { content: url(http://example.com/img/link_button_o.png) }
みたいな書き方ができればいいのかな
これなら列挙しても我慢できるレベル
正規表現が使えてまとめられるならなおよし
a[href="http://www.example.com/"]:hover:before { content: url(http://www.example.com/images/top.png); }
この記述は出来の悪いスクリプト言語にしか思えない
本来意図されているbefore,afterの使い方とは違うとおもう
これをだらだら列挙するのは精神的によろしくない
Re: (スコア:0)
IE6 氏ね!ということですね。わかります。
Re: (スコア:0)
Web開発者(特にUIのコーダー)がもっとしっかりしろって話ですね。
JS切っても見えるには見えるサイト、w3mや音声読み上げブラウザでも使えるサイトを作れる開発者をもっと増やさないといけないんですけど。W3C規格もバッチリかつユーザビリティも熟知している、そしてセキュリティ事情も追いかけてるという人が多くなればいいんですが。
# 自分はというと音声とScriptとCSSの@mediaが絡むとお手上げでまだまだ修行が足りぬ
デザイン畑出身者や、その他の人が兼業でおぼつかない知識でやってるケース、作成ソフト(と付属JSライブラリ)が古いなんてこともありますし。猫も杓子もIT業界以外もWebで情報発信の時代に、「行儀のいい」サイトを量産しようったって人手が足りないし、世間的にはWebUIなんてHTMLとCSSとJSさえかければ(書けなくたって)いいとか軽視されててそういう空気が醸成されていませんよね。規格上は住み分けできるようになっても、行儀の悪いサイトは減らないと思います。だから、理想論ですよと。
Re:JSとCSSの住み分けが進む (スコア:1)
バグを利用したワークアラウンドを多用しなけりゃお話にならないわけで。
ブラウザ開発側も直そうと思えば直せたはずなんだが、古典的「それは仕様です」になっちまってるし。
Re: (スコア:0)
Re: (スコア:0)
オフトピなのかも知れませんが、お話を伺えば伺うほど、Web「サイト」は良くてもWeb「アプリ」なんて馬鹿げてる、と思わざるを得ませんね。実際私もそう思ってます。
サーバから情報を概ね一方的に提供するWeb「サイト」は、おっしゃるやりかたで構築できるんだろうと思います。
が、Web「アプリ」となると、まともな使い心地を得ようとしたらJSなしの「なにかするたびに画面遷移を強制される画面モデル」はユーザに苦痛しか与えません。だからこそAjaxなんてな発想が持ち出され、更には使われているのですから。
FlashなりJavaAppletなりといった「まともな」クライアントアプリ開発技術で、しかも今のJSと違って「ブラウザと完全地続きというわけではない(ある程度分離された)」技術、を使うのが望ましそうですね。
もしかして悲しむべきは、それらのクライアント開発技術のほうには、Webと違って、企業非依存な「標準」が存在しないという点なのかも知れません。
Re: (スコア:0)
Re:NoScript (スコア:3, 興味深い)
Re:NoScript (スコア:3, すばらしい洞察)
そう?
基本的に全サイトを禁止。っていうのは普通だと思うけど。
使ってればわかると思うけど
NoScriptはそのページを1回目は問答無用でFlash,JavaScript禁止。
で、そのページでFlash,JavaScriptを見たかったら、右下のステータスバー上のアイコンで
ちょこちょこっと押せば、そのページは見れるわけだから全然困ってない。
今後ずっと有効 or 今だけ有効 が選べるし、
1ページ内に複数のサイトのFlash(JavaScript)があった時に
有効にするサイトも選べるし。
>私はNoScriptを入れてるけど、いつもは無効にしてる。
逆に質問。
じゃあなぜ入れてるの?
Re:NoScript (スコア:1)
>逆に質問。
>じゃあなぜ入れてるの?
JavaScriptがうざいページ(右クリック禁止とか)でJavaScriptを切るためですなw
Re:NoScript (スコア:1, 興味深い)
Re:NoScript (スコア:2, 興味深い)
YesScriptはほんの少しの時間しか使ってないので細かいところまでは見てないのですが、ステータスバーのボタン一発で禁止出来るのは便利なのですが、禁止したのを解除する時はいちいち設定ウィンドウを開いてリストから削除する必要があります。また、NoScriptはページ内のJavaScriptをサイト毎に禁止するかどうかが指定出来ますが、YesScriptは一括指定なのも不便だなと思いました。
NoScriptで不満な点は、ブラックリスト(信頼しないサイトの一覧)が参照出来ないこと。
about:configから(オフトピ) (スコア:0)
noscript.untrustedの中に入っていませんか?
参照しづらいし場所がわかりにくいのは確かですね。
# オフトピなのでAC
Re: (スコア:0)
見落としていたのかと思って、NoScriptオプションウィンドウの中を探し回ってしまったじゃないか。
#こういう突っ込みが入るとは思わなんだ。
Re:NoScript (スコア:1)
その程度のレベルが欲しいなら Mozilla の時代から本体機能に組み込まれています。user.js/prefs.js や about:config から書き変えなくても抑制できますが。以下の部分で設定変更できます。
SeaMonkey (en): [Edit] - [Preferences] - [Advanced] - [Scripts & Plug-ins] - Allow scripts to: [Disable or replace context menus] のチェックを解除
Firefox (ja): [ツール] - [オプション] - [コンテンツ] - [JavaScript を有効にする] - [詳細設定] - 次のスクリプトを許可する: [コンテキストメニューを無効化または変更する] のチェックを解除
もっとも、チェックが入っていても nglayout.events.dispatchLeftClickOnly が true (初期値) だと JavaScript に渡されるクリックイベントは左クリックのみとなるため、JavaScript におけるコンテキストメニューの制御/抑制は実際には機能しないんですけどね。
Re:NoScript (スコア:1)
それよりはクリック一発で任意に切り換えられるアドオンいれとく方が簡単でいいなあ。
あと右クリックが有効になって欲しい場合もあるわけですよ。
私の身近な例ではmodxの管理画面とか。
Re:NoScript (スコア:2, すばらしい洞察)
デフォルト設定でフィルタリストを購読できる AdBlock (Plus) とは対照的に
NoScript のデフォルト設定はフツーに閲覧するには安全なほうに倒れているので安心安心。
私はNoScriptを入れてるから、常に有効にしている。
JavaScript が必要なページはそんなに多くないし、必要ならその場でサイト単位で有効にしてあげればすむ話。
Re:NoScript (スコア:1)
NoScript で気になるのがステータスバーからの許可はセカンドレベルドメインとだけと云うこと。
コンテキストメニューはあまり増やさないようにしているのでフルドメイン、フルアドレスのホワイトリストが気軽に出来ず機能を削がれている感じ。
国内のサービスではセカンドレベルドメイン以下に ID を振るサービスが結構あるのでどこから上申して良いのか判りませんが変更されると良いなと思ったり。
Re:NoScript (スコア:1)
ちょっと前まではフルドメイン、フルアドレスがなかったのですが今改めて試したらありました。
バージョンアップなのか見落としなのか判りませんがありがとうございます。
Re: (スコア:0)
安全性と利便性はトレードオフというのは理解できるけど、
NoScriptのデフォルト設定は十年以上前のサイトですら
満足に閲覧できないだろうという堅さを感じる。
text/plainでも可読性を保てるサイトだけ閲覧するならまだしも、
新しいサイトにアクセスするたび登録しなければならない。
いや、危険なサイトはアクセスするだけでやられるので、
厳しい設定になるのはやむを得ないんだけどね。
でも、私には使い勝手が悪すぎたので即行で捨ててしまった。
ツールバーボタンが便利です (スコア:1)
少し前のバージョンからツールバーにボタンを追加できるようになったのでそちらを使っています
ツールバーボタンからならワンクリックでドメインごとの一時的な許可ができます
Re:ツールバーボタンが便利です (スコア:1)
一時的な許可であろうと、自分はやっぱり一応はサイト一覧を確認したいので、ステータスバーのアイコンのメニューの方が便利です。ボタンがトグル(許可/解除)じゃないので場所も取るし。
いつも行くところでサイト一覧の確認が必要ないのなら、永続的に許可しちゃえばいいのだし。
Re: (スコア:0)
普段w3mなので、ぜんっぜん違和感ないです。
普段行くページはホワイトリストに突っ込めばいいし。
なるほどー (スコア:1, おもしろおかしい)
私の物欲のせいかと思っていたのですが、少し安心しました。
# そんなわけないのでAC
Google検索のアレもそうですよね? (スコア:1)
あれもクリックジャックですよね。
反応が返ってくるのが遅くなる事があるのが嫌なので切れるものなら切りたいですねえ。ブラウザ側で対策できるものなのでしょうか。
現時点では情報不足 (スコア:1)
発見者の一人である Jeremiah Grossman さんのブログ記事「(Cancelled) / Clickjacking - OWASP AppSec Talk [blogspot.com]」を読んでみました。
ブログ記事に対する僕の理解が正しければ、「クリックジャック」とは、ユーザーが悪意のあるページを訪れて、そのページの中でマウスボタンをクリックすると、ユーザーの意図しない動作が引き起こされることのようです。これが脆弱性? 悪意のあるページを訪れてしまった以上、そのページの中の何がどういう動作をしようが、それってブラウザー等の脆弱性ではないのでは?
ということで、発見者が何を問題視しているのかわかりませんでした。もっと詳しい説明があれば理解できるかもしれませんが、今出ている情報だけでは理解できなくても仕方がないように思います。速やかに必要な修正が行われて詳細が公表されることを期待することにします。
Re:現時点では情報不足 (スコア:2, 興味深い)
悪意あるページ内部だけで、クリックジャックがあることによってできる何かは思いつかない。
1を聞いて0を知れ!
Re:現時点では情報不足 (スコア:1)
なるほど! そういう可能性に気付きませんでした。ご指摘ありがとうございます。たしかにそれができると非常にまずいことになりそうです。
#1427610 [srad.jp] で
と書きましたが、読み手によっては推測できるんですね。失礼しました。
Re:現時点では情報不足 (スコア:1)
「マウスボタンで (画面上の何かを) クリックする」も「マウスボタンをクリックする」も普通の言い方ですよ。
Adsenseを踏ませたりはできないのか (スコア:0)
http://www.breakingpointsystems.com/community/blog/clickjacking [breakingpointsystems.com]
のようなものしか見つけられず。真っ先に思いついたのは、ランキングサイトやAdsenseなど踏んづけて欲しいものを訪問者の意図に反して踏ませるものですが、これでは無理か。
Re:Adsenseを踏ませたりはできないのか (スコア:5, 参考になる)
AdSenseは広告の上にマウスが来た回数を計測してる。(今月初旬に確認)
具体的には、onmouseoverで広告のURLの最後にn=1、n=2と回数を追加している。
不正クリック排除のためにマウスがやってきてクリックしたと確認しているのか、
それともユーザーがどれぐらいカーソルをうろうろさせているかを計測しているのか、
ソースを確認してこの事実を知ったときは鳥肌が立った。
もし、不正クリック排除のためにやっているならば、クリックジャックのような手段でクリックさせていると
即効でバレてBANじゃないかな。
Re:Adsenseを踏ませたりはできないのか (スコア:1)
大概のことは、悪いヤツのほうが有能なんだよねぇ...
# などとボヤいてみる
M-FalconSky (暑いか寒い)
Re:Adsenseを踏ませたりはできないのか (スコア:1)
ただし、いつまでこの仕様かわからないので、「仕様変更!n=付いてたらアウトね!」なんてことになると一瞬でばれる。
このあたりはいたちごっこになる要素は多分にあるものの、やはり提供側が簡単にソースを変更できるので強い。
喜ぶべきか、悲しむべきか… (スコア:0)
(´-`).。oO(w3mも影響を受けるのか、誰も存在を覚えていないのか…)