パスワードを忘れた? アカウント作成
36026 story

ユーザのクリックを乗っ取る「クリックジャック」 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, 興味深い)

    by Anonymous Coward on 2008年09月27日 17時51分 (#1427328)
    書くかどうか、2時間ぐらい悩んだけども、おいちゃんにわかるってことはみんなもわかってるんだろうと思って、結局書き込むことにした。
    ただ、チキンなのでACで。

    これは、CSSを使って、透過したFlashをウィンドウの全面に貼付けて、クリックを奪ってしまう、ってことなんだろう。
    実際に実行コードも書いてみたけど、見事にちゃんと、記事のとおりになった。
    (と、ここでかっこ良くサンプルページを貼付けたいんだけど、あまりにも単純すぎて、コピペでそのまま悪用できるのでやめた)

    実際にスクリプトはFlashの中で動くので、JavaScriptが切ってあっても問題ない。
    JavaScript をターゲットのページに投げるのは一筋縄ではいかないけど、Flashになれてる人なら簡単だろう。
    逆に考えると、Flashの中で生成できるので、例えば現在のURLにパラメタを追加して投げるとか、そのページ内に存在しない何かをどこかに向かって投げるとかも簡単。

    これを防ぐには、ユーザーレベルでは、Flashを切る or CSS を切るかどちらか。
    Adobeが根本的に対応するには、Flashの背景(ステージ)の透過を出来ないようにするしか無い。

    これはあまりにも簡単で、何でも出来て、ぱっと見バレにくいから、攻撃として流行りそうな気がする。
    しかも、出ている情報だけでわかる人にはわかってしまう、一番中途半端で問題の多いパターンだと思う。
    だから、詳しく書いてみた。
    • Re:CSS + Flash (スコア:3, 興味深い)

      by Anonymous Coward on 2008年09月27日 23時23分 (#1427501)
      以前、今回の件に良く似た IE の不思議な動作を見つけましたが、
      何か関係があるのかもしれません。
      ただし Firefox では動作しなかったので、別件だとは思いますが...

      <a href="http://srad.jp/">
      <iframe width="300" height="300" src="http://google.com/"></iframe></a>
      こんなふうに <iframe> 要素全体を <a> で括ってやると、
      iframe 内の任意の箇所(リンクは除く)をクリックすると <a> が動きます。
      上記例では、iframe 内の google ページの適当なところをクリックすると、
      スラドが開いてしまうというものです。

      ウィンドウ全体に広がるような iframe を作成して、
      アフィリエイト等のクリックさせたい URL に向けたリンクで囲ってやれば、
      何か面白いことができそうだね、という話をしていたのですが...
      親コメント
    • Re:CSS + Flash (スコア:2, 興味深い)

      by poundcake (11852) on 2008年09月28日 6時20分 (#1427573) 日記
      まるっきり素人考えですが、これだとすると、いわゆるphishingとの違いは、予想しないところにリンクがあることでしょうか? 得体の知れないリンクはもとから危険なんでしょうし。

      そうだとすると透過を禁止するだけではなく、リンクのあるところでは必ずカーソルが変わる、という仕様が必要ではないですか。脱出系Flashゲームは専用のブラウザでやることに…?
      親コメント
    • Re:CSS + Flash (スコア:1, 興味深い)

      by Anonymous Coward on 2008年09月27日 18時21分 (#1427346)

      クリックジャックはOWASP NYC AppSec 2008 ConferenceにてProof of Conceptとともに発表されるはずだったが、Adobeや他ベンダーからの要請により、発表はベンダーが対策を準備できるまで延期されたとのこと。
      親コメント
      • by funakichi (28497) on 2008年09月27日 23時07分 (#1427493)
        ZDZetの日本語訳を読んだかんじでは、AppSec 2008 で議論する事を取りやめ、また(参加者が限られた)カンファレンス外への発表を自粛したと言うことであって、発表はあったって事じゃないのかしらん。
        #この解釈で正しいのだとすると、記事自体がわかりにくいんだけれども…
        親コメント
    • Re:CSS + Flash (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2008年09月28日 8時42分 (#1427588)
      そういう広告たまに見ますね。
      画面全体にぱらぱらと、なにかが落ちてきたりするFlash。
      もちろん、どこかクリックしないとはじまらないというのが多い気がしますけど。
      親コメント
  • デフォルト設定ではなにもブロックしてくれないAdblockとは対照的に、
    NoScriptのデフォルト設定はフツーに閲覧するには少々厳しすぎない?

    私はNoScriptを入れてるけど、いつもは無効にしてる。
    • by Anonymous Coward on 2008年09月27日 15時20分 (#1427251)
      # 理想論だってのは最初から認めたうえで
      Javascriptを視覚エフェクトとしてつかっているサイトは非常に多いと思いますが、Scriptなしでも最低限の機能は提供するのがうまい設計であって、切るだけでボロ崩れ/飛べない場所が出る等の機能不全を起こすのはダメダメといえます。

      CSS2.1(の主にセレクタ)をフルに使えるブラウザに最適化されたサイトは、この部分にさえ、Javascriptを多用する必要はありませんよね。
      これから視覚エフェクトはCSS一本に、Javascriptはそれ以外にと住み分けが進んでいくと思います。

      # Noscriptはホワイトリストで使ってますが、まともに見れなくなるダメサイト結構多い。
      親コメント
      • 画像使わなくて良いならcssで十分表現力があるんだけど
        画像使わないなんて事は上が許してくれないわけで・・・
        そうなるとcssじゃ全然足らないよ・・・
        親コメント
        • CSS の表現能力が足りないのではなく、ブラウザの CSS 実装レベルが足りないって方が現実に合っているかと思いますが。
          画像を使うと CSS じゃ無理、なんてのはかなり意味不明です。

          親コメント
          • 例えばアクティブなアンカーを目立つようにするにはどうするか?

            アンカーがテキストだったらcssで「全部共通で」色を変更したり指定できる

            アンカーが画像だったらどうする?
            単純にimgタグを使う場合cssでは違う画像に変更するなんてできないよね

            background-imageで指定してそれを切り替えるという手段もあるけど
            その場合すべての画像を使ったアンカーに対してcssを書かないといけなくてとても面倒だしサイズが大きくなるよね

            だからjs使ってmouseoverで画像切り替えるような処理にするのは当然の方向性だよね
            親コメント
            • アンカーが画像だったらどうする?
              単純にimgタグを使う場合cssでは違う画像に変更するなんてできないよね

              a 要素の内容に img 要素しか置かないならこれでできますけど。

              a[href]:hover > img { display: none; }

              a[href="http://www.example.com/"]:hover:before { content: url(http://www.example.com/images/top.png); }
              a[href="http://www.example.com/content1/"]:hover:before { content: url(http://www.example.com/images/content1.png); }
              a[href="http://www.example.com/content2/"]:hover:before { content: url(http://www.example.com/images/content2.png); }

              URL 完全一致ではなく、前方一致でやりたいなら a[href^="..."] ですね。CSS3 Selectors になりますが、Gecko や WebKit 系なら普通に対応してます。CSS3 Selectors 的には :before ではなく ::before ですか。
              後は元の HTML 側でリンク先ごとに個別の画像を a 要素の内容に置いておけばいいですね。

              この程度の列挙でも面倒だけど JavaScript なら面倒じゃない、とはとても考えられないほど簡単なレベルだと思います。どうでしょうか。この書き方なら代替表示する画像も一括管理可能です。

              そして、リンクがある HTML 文書が 1 つしかないのであればともかく、複数の HTML 文書から成立しているのであれば、この程度の記述の列挙程度は (どうせ CSS もキャッシュされるものですし) トータルサイズ自体はより小さく収まるでしょうね。

              ただし IE6/7 は CSS2 以降への準拠度が激しく低いため、現実的に IE が想定される場面においてこれは使えません。元コメントでの意はその点を指しています。

              background-imageで指定してそれを切り替えるという手段もあるけど
              その場合すべての画像を使ったアンカーに対してcssを書かないといけなくてとても面倒だしサイズが大きくなるよね

              全リンクを onload 時に拾って onmouseover イベントを個別に埋め込んでいくのはクライアント環境にとっては製作者側の負担を閲覧者側に押し付ける無駄な処理でしかありませんから、結局 JavaScript でも HTML に対して個別に onmousehover を設定する事にならないでしょうか。
              CSS を使った方がサイト全体の HTML に対して埋め込み忘れがないかを気にせず書ける点で、管理コストを下げる面においても有利でしょう。

              background-image でないと CSS で似たようなことができないというのは、IE が上のような記述を行っても動作しないからです。それは CSS だけではできない事ではなく Web ブラウザ側の問題です。
              少なくともその程度の範囲であれば「IE がタコだからこの程度の事でも JavaScript じゃないとだめなんだよね」と言うのは納得できますが、「CSS がタコだから~」と言うのは CSS を分かってないだけとしか思えません。

              親コメント
              • a[href]:hover > img { display: none; }

                a[href="http://www.example.com/"]:hover:before { content: url(http://www.example.com/images/top.png); }
                a[href="http://www.example.com/content1/"]:hover:before { content: url(http://www.example.com/images/content1.png); }
                a[href="http://www.example.com/content2/"]:hover:before { content: url(http://www.example.com/images/content2.png); }
                この列挙が面倒じゃないって本気で言ってる?
                凄まじく面倒です

                a:hover:before > img.chimg[src="(.*).(.*)"] { content: url($1_o.$2); }
                適当に書いてみましたがこれくらいの1行で「サイト内すべて」の画像切り替えが実現できないと使えるとは言えない
                親コメント
              • 本気で言ってますよ。それでもサイト全体の全文書に JavaScript を埋め込むよりマシですから。CSS は on だけど JavaScript が off だと全く機能しないようなものよりはマシだし、ある程度量が増えたら make 一発生成とかして終わりになるだけでしょうから。

                それと、正規表現的にあまりにもありえなさすぎる例示なのでエスパー解釈してみようと思いましたが、CSS でひたすら列挙する方がコスト的に少ない点と漏れが出る可能性が低い点、確認コストが少ない点などから確実にマシですね。HTML 側はサイト共通スタイルシートの指定以外何も文書をいじる必要がないのですから。

                それと、img 要素の src にそんな単純な範囲で指定できるなら、そもそも class 指定すら不要に思えますね。

                親コメント
              • >CSS でひたすら列挙する方がコスト的に少ない点

                まずサイズ
                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を使うのが間違いっていうのは納得できないね
                親コメント
              • 1つのリンクに対して約100byteとすると
                リンクが10000あったらそれだけで1Mbyte
                そんなサイズのcssは今のところ現実的ではないですね

                そりゃあり得ないですよね。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 が生成される事の方が稀ではないでしょうか。

                そもそも「ユーザの行動に対して画像を切り替える」事を実現するのにjsを使うのが間違いな訳がないよね
                googleMapもおなじだもんね

                IE 等を考慮すると現実的な解としては結局 JavaScript になる、という点については全く否定していないのですが、何か勘違いしていませんか?

                もう一度最初に書いたコメントを繰り返しておきますね。

                CSS の表現能力が足りないのではなく、ブラウザの CSS 実装レベルが足りないって方が現実に合っているかと思いますが。
                画像を使うと CSS じゃ無理、なんてのはかなり意味不明です。

                親コメント
              • >CSS の表現能力が足りないのではなく、ブラウザの CSS 実装レベルが足りないって方が現実に合っているかと思いますが。
                >画像を使うと 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の使い方とは違うとおもう
                これをだらだら列挙するのは精神的によろしくない
                親コメント
      • by Anonymous Coward
        > # 理想論だってのは最初から認めたうえで

        IE6 氏ね!ということですね。わかります。
        • by Anonymous Coward
          IEだってJSやCSSを切るくらいはできるのでIE6氏ねって話ではなく

          Web開発者(特にUIのコーダー)がもっとしっかりしろって話ですね。
          JS切っても見えるには見えるサイト、w3mや音声読み上げブラウザでも使えるサイトを作れる開発者をもっと増やさないといけないんですけど。W3C規格もバッチリかつユーザビリティも熟知している、そしてセキュリティ事情も追いかけてるという人が多くなればいいんですが。
          # 自分はというと音声とScriptとCSSの@mediaが絡むとお手上げでまだまだ修行が足りぬ

          デザイン畑出身者や、その他の人が兼業でおぼつかない知識でやってるケース、作成ソフト(と付属JSライブラリ)が古いなんてこともありますし。猫も杓子もIT業界以外もWebで情報発信の時代に、「行儀のいい」サイトを量産しようったって人手が足りないし、世間的にはWebUIなんてHTMLとCSSとJSさえかければ(書けなくたって)いいとか軽視されててそういう空気が醸成されていませんよね。規格上は住み分けできるようになっても、行儀の悪いサイトは減らないと思います。だから、理想論ですよと。
          • そもそも人気のあるブラウザがどれもCSSに関してはバグバグファイアーなのがいかん。
            バグを利用したワークアラウンドを多用しなけりゃお話にならないわけで。

            ブラウザ開発側も直そうと思えば直せたはずなんだが、古典的「それは仕様です」になっちまってるし。
            親コメント
            • by Anonymous Coward
              IEはどうだか知りませんが、IE以外のブラウザにバグと称して報告されるものの大半は「IEと動作が違う」であって、「それは仕様です」としか答えようがないのですが。
          • by Anonymous Coward
            >JS切っても見えるには見えるサイト、w3mや音声読み上げブラウザでも使えるサイトを

            オフトピなのかも知れませんが、お話を伺えば伺うほど、Web「サイト」は良くてもWeb「アプリ」なんて馬鹿げてる、と思わざるを得ませんね。実際私もそう思ってます。

            サーバから情報を概ね一方的に提供するWeb「サイト」は、おっしゃるやりかたで構築できるんだろうと思います。

            が、Web「アプリ」となると、まともな使い心地を得ようとしたらJSなしの「なにかするたびに画面遷移を強制される画面モデル」はユーザに苦痛しか与えません。だからこそAjaxなんてな発想が持ち出され、更には使われているのですから。

            FlashなりJavaAppletなりといった「まともな」クライアントアプリ開発技術で、しかも今のJSと違って「ブラウザと完全地続きというわけではない(ある程度分離された)」技術、を使うのが望ましそうですね。

            もしかして悲しむべきは、それらのクライアント開発技術のほうには、Webと違って、企業非依存な「標準」が存在しないという点なのかも知れません。
            • by Anonymous Coward
              Google maps以外のAJAX使用サイトなんて使ってて苦痛を感じるものばかりなんですが?
    • Re:NoScript (スコア:3, 興味深い)

      by Anonymous Coward on 2008年09月27日 13時59分 (#1427218)
      そのくせ作者サイト関係のドメインが標準でホワイトリストに入っていたりしてなんか怖い
      親コメント
    • Re:NoScript (スコア:3, すばらしい洞察)

      by Anonymous Coward on 2008年09月27日 16時05分 (#1427276)
      >NoScriptのデフォルト設定はフツーに閲覧するには少々厳しすぎない?
      そう?
      基本的に全サイトを禁止。っていうのは普通だと思うけど。

      使ってればわかると思うけど
      NoScriptはそのページを1回目は問答無用でFlash,JavaScript禁止。
      で、そのページでFlash,JavaScriptを見たかったら、右下のステータスバー上のアイコンで
      ちょこちょこっと押せば、そのページは見れるわけだから全然困ってない。

      今後ずっと有効 or 今だけ有効 が選べるし、
      1ページ内に複数のサイトのFlash(JavaScript)があった時に
      有効にするサイトも選べるし。

      >私はNoScriptを入れてるけど、いつもは無効にしてる。
      逆に質問。
      じゃあなぜ入れてるの?
      親コメント
      • >>私はNoScriptを入れてるけど、いつもは無効にしてる。
        >逆に質問。
        >じゃあなぜ入れてるの?

        JavaScriptがうざいページ(右クリック禁止とか)でJavaScriptを切るためですなw
        親コメント
        • Re:NoScript (スコア:1, 興味深い)

          by Anonymous Coward on 2008年09月27日 19時45分 (#1427394)
          その用途ならブラックリスト方式のYesScript [mozilla.org]のほうがいいと思います。

          親コメント
          • Re:NoScript (スコア:2, 興味深い)

            by Anonymous Coward on 2008年09月27日 20時21分 (#1427412)
            YesScriptは解除が面倒。間違って禁止してしまった時に面倒だなと感じました。もう少しインタフェースが充実してくれればYesScriptも便利そうなんだけど、それならNoScriptをブラックリスト方式で運用しても同じだし。(『全てのJavaScriptを許可(危険)』で使って、必要に応じて信頼しないサイトに指定)

            YesScriptはほんの少しの時間しか使ってないので細かいところまでは見てないのですが、ステータスバーのボタン一発で禁止出来るのは便利なのですが、禁止したのを解除する時はいちいち設定ウィンドウを開いてリストから削除する必要があります。また、NoScriptはページ内のJavaScriptをサイト毎に禁止するかどうかが指定出来ますが、YesScriptは一括指定なのも不便だなと思いました。

            NoScriptで不満な点は、ブラックリスト(信頼しないサイトの一覧)が参照出来ないこと。
            親コメント
            • >NoScriptで不満な点は、ブラックリスト(信頼しないサイトの一覧)が参照出来ないこと。

              noscript.untrustedの中に入っていませんか?

              参照しづらいし場所がわかりにくいのは確かですね。

              # オフトピなのでAC
              • by Anonymous Coward
                そりゃどっか(prefs.js)に保存はしてるんだから、そういう所(about:config)を見れば参照出来ることは知ってますよ。

                見落としていたのかと思って、NoScriptオプションウィンドウの中を探し回ってしまったじゃないか。

                #こういう突っ込みが入るとは思わなんだ。
        • by Stealth (5277) on 2008年09月29日 11時31分 (#1428152)

          JavaScriptがうざいページ(右クリック禁止とか)でJavaScriptを切るためですなw

          その程度のレベルが欲しいなら 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 におけるコンテキストメニューの制御/抑制は実際には機能しないんですけどね。

          親コメント
          • お説ごもっとも。だが少々面倒ではないですか。
            それよりはクリック一発で任意に切り換えられるアドオンいれとく方が簡単でいいなあ。

            あと右クリックが有効になって欲しい場合もあるわけですよ。
            私の身近な例ではmodxの管理画面とか。
            親コメント
    • Re:NoScript (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2008年09月27日 14時02分 (#1427222)
      使っているアドオンが異なると、設定もだいぶ変わるもんですねぇぃ

      デフォルト設定でフィルタリストを購読できる AdBlock (Plus) とは対照的に
      NoScript のデフォルト設定はフツーに閲覧するには安全なほうに倒れているので安心安心。

      私はNoScriptを入れてるから、常に有効にしている。
      JavaScript が必要なページはそんなに多くないし、必要ならその場でサイト単位で有効にしてあげればすむ話。
      親コメント
    • by STRing (14928) on 2008年09月27日 21時33分 (#1427444) 日記
      ステータスバーのアイコンから(一時的|常)に許可をすればすぐなので厳しいとは思いません。IFRAME もまずチェックする項目です。

      NoScript で気になるのがステータスバーからの許可はセカンドレベルドメインとだけと云うこと。
      コンテキストメニューはあまり増やさないようにしているのでフルドメイン、フルアドレスのホワイトリストが気軽に出来ず機能を削がれている感じ。
      国内のサービスではセカンドレベルドメイン以下に ID を振るサービスが結構あるのでどこから上申して良いのか判りませんが変更されると良いなと思ったり。
      親コメント
    • by Anonymous Coward
      御意。

      安全性と利便性はトレードオフというのは理解できるけど、
      NoScriptのデフォルト設定は十年以上前のサイトですら
      満足に閲覧できないだろうという堅さを感じる。

      text/plainでも可読性を保てるサイトだけ閲覧するならまだしも、
      新しいサイトにアクセスするたび登録しなければならない。
      いや、危険なサイトはアクセスするだけでやられるので、
      厳しい設定になるのはやむを得ないんだけどね。

      でも、私には使い勝手が悪すぎたので即行で捨ててしまった。
      • 自分も最初は「一時的に許可」がスマートにできないのが気に入らなかったのですが
        少し前のバージョンからツールバーにボタンを追加できるようになったのでそちらを使っています
        ツールバーボタンからならワンクリックでドメインごとの一時的な許可ができます
        親コメント
        • >ツールバーボタンからならワンクリックでドメインごとの一時的な許可ができます

          一時的な許可であろうと、自分はやっぱり一応はサイト一覧を確認したいので、ステータスバーのアイコンのメニューの方が便利です。ボタンがトグル(許可/解除)じゃないので場所も取るし。

          いつも行くところでサイト一覧の確認が必要ないのなら、永続的に許可しちゃえばいいのだし。
          親コメント
    • by Anonymous Coward
      だがそれがいい。

      普段w3mなので、ぜんっぜん違和感ないです。
      普段行くページはホワイトリストに突っ込めばいいし。
  • なるほどー (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2008年09月27日 16時01分 (#1427273)
    気がついたらiTunesとかAmazonで使った金額がアレなことになっているのは、実はクリックジャックのせいだったのですね。
    私の物欲のせいかと思っていたのですが、少し安心しました。
    # そんなわけないのでAC
  • Googleの検索結果をクリックした瞬間、リンク先がGoogleのサイトになってそこから元あったリンク先にリダイレクトされますよねえ。
    あれもクリックジャックですよね。
    反応が返ってくるのが遅くなる事があるのが嫌なので切れるものなら切りたいですねえ。ブラウザ側で対策できるものなのでしょうか。
  • 発見者の一人である Jeremiah Grossman さんのブログ記事「(Cancelled) / Clickjacking - OWASP AppSec Talk [blogspot.com]」を読んでみました。

    ブログ記事に対する僕の理解が正しければ、「クリックジャック」とは、ユーザーが悪意のあるページを訪れて、そのページの中でマウスボタンをクリックすると、ユーザーの意図しない動作が引き起こされることのようです。これが脆弱性? 悪意のあるページを訪れてしまった以上、そのページの中の何がどういう動作をしようが、それってブラウザー等の脆弱性ではないのでは?

    ということで、発見者が何を問題視しているのかわかりませんでした。もっと詳しい説明があれば理解できるかもしれませんが、今出ている情報だけでは理解できなくても仕方がないように思います。速やかに必要な修正が行われて詳細が公表されることを期待することにします。

  • by Anonymous Coward on 2008年09月27日 16時12分 (#1427280)
    いくつかリンクをたどって見たけれど、

    http://www.breakingpointsystems.com/community/blog/clickjacking [breakingpointsystems.com]

    のようなものしか見つけられず。真っ先に思いついたのは、ランキングサイトやAdsenseなど踏んづけて欲しいものを訪問者の意図に反して踏ませるものですが、これでは無理か。
  • by Anonymous Coward on 2008年09月27日 17時39分 (#1427321)

    影響を受けないブラウザはLynxくらいだそうだ

    (´-`).。oO(w3mも影響を受けるのか、誰も存在を覚えていないのか…)
typodupeerror

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

読み込み中...