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

Mozillaベースのブラウザにプライバシ漏洩の危険性 56

ストーリー by Oliver
逆Referer 部門より

Anonymous Coward曰く、"本家発。Mozillaベースのブラウザにバグが見つかった模様。現在閲覧しているJavaScriptのonunloadハンドラを定義しているサイトに、次に移動したページを知られてしまうというもの。ハイパーリンクのクリック、URLの手打ち、ブックマークからの選択、と、どの場合でも起こる。実演と対処方法が公開されている。対象となるブラウザは、Mozilla 0.9x, 1.0, 1.0.1, 1.1, 1.2alpha、Netscape 6.x, 7、Galeon 1.2.x、Chimera 0.5。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 対処法 (スコア:5, 参考になる)

    by MLC (6565) on 2002年09月18日 7時54分 (#167864) ホームページ 日記
     知っている人は多いと思いますが、一応転載しておきます。
     Mozilla-gumi BBS [mozilla.gr.jp]より:

     (2) user.js に以下を書くことによって referer の送出を止める。

            user_pref("network.http.sendRefererHeader", 0);

     (3) HTTP referer を削除するproxyソフトを利用する。

     (4) javascript の実行を禁止する。
            (「場当たり的な対応」)

    とのことです。

     なお、

     (1) プロファイルのあるフォルダ(pref.jsのある所)に
      user.js というファイルを作り、その中に以下の行を書くことに
      よって onunload ハンドラの動作を抑制する。

     user_pref("capability.policy.default.Window.onunload", "noAccess");

    には、抜け穴があるので完璧ではないとの情報アリ。
    --
      --- Melloques Les Covdrasey ---
    • Re:対処法 (スコア:2, 参考になる)

      by Anonymous Coward on 2002年09月18日 8時56分 (#167873)
      しかし、Referer の送出を止めると、悪戯防止のために Referer をチェックしてる掲示板などに書きこみできなくなる場合が出て来ると思われる。
      掲示板だけじゃなくて、CGI では結構そういうチェックの入ってるのが見られる。
      親コメント
      • Re:対処法 (スコア:2, 参考になる)

        by MLC (6565) on 2002年09月18日 9時21分 (#167882) ホームページ 日記
        > Referer の送出を止めると、悪戯防止のために Referer をチェックしてる掲示板などに書きこみできなくなる場合が出て来ると思われる。

         確かに、ここがイタイところですね。

         ここに不都合がある人は、当面、

         (3) HTTP referer を削除するproxyソフトを利用する。
         (4) javascript の実行を禁止する。

        のどちらかで、対処するしかないかも。
         (今回の件に関わらず、javascriptは止められる限り止めといた方がヨサゲですし)

         私自身は、前からRefererは止めてますが、あまり不都合は感じていません。
         たぶん、幸せな環境で生きているのでしょう。(^^;

         Refererチェックの有る業務用の掲示板は、どうせIE専用ですし・・・。(ToT)
        --
          --- Melloques Les Covdrasey ---
        親コメント
        • by ksada (4435) on 2002年09月18日 11時48分 (#167952)
          >> ここに不都合がある人は、当面、
          >> (3) HTTP referer を削除するproxyソフトを利用する。

          Referer が行かなくなるのは同じじゃないの?
          親コメント
          • by MLC (6565) on 2002年09月18日 12時01分 (#167960) ホームページ 日記
            >> (3) HTTP referer を削除するproxyソフトを利用する。
            > Referer が行かなくなるのは同じじゃないの?

             うわっ、ホントだ(笑)
             気をつけたつもりだったのに、コピペのときに消し忘れました。
             すみません。脳内削除しておいて下さい。m(_ _)m
            --
              --- Melloques Les Covdrasey ---
            親コメント
          • by Anonymous Coward
            全てのrefererではなく
            選択的に行くように/行かないようにすることは容易です
            proxyの種類によりますけど
            そのような機能がなくてもアレゲ掲示板の住人なら
            数分でハック完了でしょう :-)
            • by Anonymous Coward
              というか,それが数分でハック完了なら,
              元々の問題も数時間くらいでハック完了しないの?

              # できないので,というより正確にはやろうとしないので AC
              • by Anonymous Coward
                > というか,それが数分でハック完了なら,
                > 元々の問題も数時間くらいでハック完了しないの?

                だから"本気でやらんかゴルァ"とのお怒りのあと、あっという間にpatchが出来上がってます。

                see Bugzilla bug 145579 [mozilla.org].
      • by Anonymous Coward
        同一サーバーへのみReferer送るようにすれば問題なし
  • phoenixも対象かと (スコア:3, 参考になる)

    by suezo (2881) on 2002年09月18日 9時04分 (#167877) 日記
    phoenixだけ抜けてるにもちと悲しい。
    • by Anonymous Coward
      というか、「対象となるブラウザ」と明確に書いてる以上、
      そこにないという事は「phoenixには問題がない」と
      読めてしまいます。
      ・・・実際問題なかったりして。今手元にないので誰か確認希望。
  • by T.Sawamoto (4142) on 2002年09月18日 9時55分 (#167896)
    Mozilla1.1で試してみたんですが、リンクを"Open Link in New Window"または"Open Link in New Tab"で移動した場合には漏洩は起きないようですね。(当然?)
    URL直打ち/Bookmark選択は新しいウィンドウ/タブから行うということにしておけば、当座はしのげると考えていいのかな?
    • さんざんあちこち飛び回った後で「あ、あのページに何て書いてあったかな」なんて思うと結構大変なので、最近は、別のサイトへ移るようなジャンプやちょっと気にしておくべきと認識したページから次へのジャンプなんかは新規タブでやるように心がけています。その代わりタブでいっぱいになってしまいますが。(笑)ウィンドウががんがん増殖するのに比べて見やすいので助かっています。

      で、一応マジレスしておくと、この形態で漏洩が起こらないのはページをunloadするという操作が発生しないのだから当然だと思われます。同一画面内で遷移が発生する場合にunloadの瞬間と次のurlへのジャンプがワンアクションとして発生するので漏洩しているのでしょう。
      親コメント
  • えぇと,JavaScript 切るだけじゃダメで
    user.js 作ってやらねばいかんと言う事で宜しいのでしょうか?

    最近 Mozilla しか使ってないので,こんな場合一寸だけ不安(^_^;
  • by Anonymous Coward on 2002年09月18日 7時14分 (#167859)
    ウム。。
    2002/09/04に気がついて直してるけども

    # どれで、気がついたか覚えてない..AC

  • by Anonymous Coward on 2002年09月18日 9時45分 (#167892)
    ここ [excite.co.jp]で件のページを翻訳してみたんですが、
    registered=xxxxxx;とか UID=xxxxxxxxxxxxxxxx;とか NGUserID=xxxxxxxxx-xxxxxx-xxxxxxxxxxx-xx;
    とか出てしまうんですが、私だけでしょうか?
    #なんだか良く分かりませんのでAC。(xox;
    • by Anonymous Coward
       大丈夫です。
       Excite Chatもそうなっています :)
    • by Anonymous Coward
      上のACです。
      Cookieをそのまま表示することになってるのか、
      Excite翻訳のCookieがそのまま表示されているだけでした。

      セキュリティには関係ないと思われるので激しくオフトピックです。
      失礼しました。
  • by Anonymous Coward on 2002年09月18日 10時27分 (#167913)
    単に移動先のURLが知られる*だけ*だったら,(たしかにプライバシー保護の観点からはとってもマズいけど)個人的にはあまり気にならないですけど.
    具体的には,どんな困ったことが起こり得るんでしょうか?うまいことやるとクレジットカードの番号盗まれたりとかもあり得るのかな?(webで買物してないから,個人的にはそれもあまり心配じゃないけど)識者の解説をお願いします.
    • 自分のWebに来てる知人が、前にエロサイトを見てたりするとその趣味が判ったりします。
      確かにプライバシーが犯されるという意味では問題有るかも。
      人によりますが。

      これって昔IEでもよくあったリファ漏れってやつと同じかな?
      親コメント
    • 時々セッションIDなどをGETメソッドで渡しているWEBアプリケーションがあります。そんな情報がrefererにさっくりついてきちゃうワケで。
      # この危険性については雑誌やMLを通じて度々言及されています。

      株式会社@@@の開発した某サイトなんてユーザーIDとパスワードが生でGETメソッドで
      • 時々セッションIDなどをGETメソッドで渡しているWEBアプリケーションがあります。そんな情報がrefererにさっくりついてきちゃうワケで。
        それが起きるのは、ジャンプ先にジャンプ前のURLが漏れる場合で、今回は逆のようですよ。ジャンプ先のURLがジャンプ前のページに盗み見られ得るという。
        単に移動先のURLが知られる*だけ*だったら,
        ...
        具体的には,どんな困ったことが起こり得るんでしょうか?
        例えば、ここスラッシュドットでは、 ユーザページ [srad.jp]の「パスワード」 [srad.jp]のところに、
        このリンクをクリックすると,自動的にログインすることができます.クリックした先のページをブックマークしてください.全く安全ではないですが,とても便利です.
        というのがありますが、この方法でスラッシュドットにログインしている人は危険ですね。今回の罠の仕掛けられたページを表示した状態で、このブックマークを選んでスラッシュドットにログインすると、そのURLを盗まれますから、スラッシュドットのアカウントを乗っ取られることになります。
        親コメント
    • 移動先URLが知られるのではなくて、移動元URLが移動先に知られるのです。

      • > 移動先URLが知られるのではなくて、移動元URLが移動先に知られるのです。

        違います。
        それでは、ブラウザの出す環境変数「HTTP_REFERER」の値を取得した場合と変わりがなく、敢えて今回問題として取り上げられるはずもないと思います。

        タレコミ文を読んでの通りですが、該当バグの表題には、
        「Web
        • by ksada (4435) on 2002年09月18日 12時08分 (#167966)
          >> > 移動先URLが知られるのではなくて、移動元URLが移動先に知られるのです。
          >> 違います。
          >> それでは、ブラウザの出す環境変数「HTTP_REFERER」の値を取得した場合と変わりがなく、

          HTTP_REFERER の値は、すべての移動元ではなく、

          1. アンカーをたどって移動した元のページ
          2. img src= で CGI を起動した元のページ
          3. frame を指定して表示した親ウインドウ/フレーム
          4. form で CGI を起動した元のページ

          を通知します。そうでない実装もあったようですが不正な動作です。
          親コメント
          • > 2. img src= で CGI を起動した元のページ

            img src= に記述されたURIがCGIを利用したものであるか否かは
            ブラウザーにとって知る由も無いことです。
            たとえ判断するブラウザーがあったとしても
            CGIならRefererを送りCGIでなければ送らないブラウザーがあるのでしょうか?

            > 4. form で
            • >> CGIならRefererを送りCGIでなければ送らないブラウザーがあるのでしょうか?

              CGI でなければ送らないとは書いていません。確かに通常ファイルを指していても送られますが、それで悪用されるというのは考えにくいので、本トピックに関する限り注目する必要性を感じません。

              >> > そうでない実装もあったようですが不正な動作です。
              >> 不正な動作だと判断する理由がありません

              「不正な動作」は、すべての移動元を通知するという動作を指すつもりでした。
              親コメント
              • by Anonymous Coward on 2002年09月18日 19時30分 (#168210)
                > >> > そうでない実装もあったようですが不正な動作です。
                > >> 不正な動作だと判断する理由がありません
                >
                > 「不正な動作」は、すべての移動元を通知するという動作を指すつもりでした。

                そのことは伝わっております。
                ですから、「すべての移動元を通知するという動作」すなわち「1から4の条件に該当しない状況でRefererを送る動作」を不正な動作だと判断する理由がないということです。
                言い替えると、それを行ってはならないと規定しているRFCなどの
                仕様書を示して下さいということなんですね。
                (rfc2616には「リクエストURIを得た情報源のURIが存在していない場合(手入力など)はRefererを送信してはいけない」と規定されていますが、リンク方法やタグの種類などを条件とした規定は見当たりません)

                > CGI でなければ送らないとは書いていません。確かに通常ファイルを指していても送られますが、それで悪用されるというのは考えにくいので、本トピックに関する限り注目する必要性を感じません。

                確かに「CGI でなければ送らない」とは書いておりませんが、そう書いているという指摘もありません。

                書いておられるのは1から4の条件でRefererを送信するのは正当でそれ以外の状況で送信するのは不正な動作ということです。そして「img src=」にて指定されたURLをアクセスしたときRefererを送ることが正当か不正かを考えると、それに該当しそうなのは1から4の中の2だけであり、そこに「img src= で CGI を起動した元のページ」と記述されている以上、「img src= で CGI 以外をアクセスした場合」はその条件から外れると解釈されて当然だと思われます。
                その前後を総合すると、

                「img src= にて指定されたURLをアクセスしたときそれがCGIでない場合はRefererを送る動作が不正」

                という結論になってしまいます。

                それに対して「Referer送信動作の正当性にCGIは関係ないであろう」という指摘なのです。ここでの問題は、ブラウザーによるReferer送信動作が不正か正当かですので、受け取ったサーバー側でそれを悪用しやすいか否かは関係してこないことにご注意下さい。

                なお「確かに通常ファイルを指していても送られますが、それで悪用されるというのは考えにくいので、」と主張されておりますが、アクセス先がCGIであるか否かに関わらず、いずれの場合も、Referer情報を悪用したいという意志があるならば、httpアクセスログにはRefererの情報がばっちり記録されることになります。悪意なくとも有名どころのhttpdをインストールすればデフォルトでRefererとUser-Agentが記録されます。
                そのため両者違いがありませんので、CGIでないからといって安心する心構えは機器管理の観点でいえば問題ありです。
                親コメント
        • > ブラウザの出す環境変数「HTTP_REFERER」

          ブラウザーは環境変数「HTTP_REFERER」なんて出しません。
          ブラウザーそのものに存在するセキュリティーホールについて言及するならば、ブラウザーそのものがどのように動作すべきで、それが現状どのように動作しているのかを正確に掴むべきです。
          • 蛇足ですが・・・

            >> ブラウザの出す環境変数「HTTP_REFERER」の値
            > ブラウザーは環境変数「HTTP_REFERER」なんて出しません。

            環境変数「HTTP_REFERER」を出すとはいっていません。
            誤解を招く表現(もしくは正確でない?)であることは認めます。

            > ブラウザーそのものに存在するセキュリティーホ
            • >>> ブラウザの出す環境変数「HTTP_REFERER」の値 >> ブラウザーは環境変数「HTTP_REFERER」なんて出しません。 >環境変数「HTTP_REFERER」を出すとはいっていません。 ブラウザが出してるのはHTTPヘッダ。 指摘の主旨を正確
  • by Anonymous Coward on 2002年09月18日 13時02分 (#168004)

    ブラウザは見るだけのソフトってことにして
    JAVAだのスクリプトだのあやしいことはクライアント側で一切しない
    って訳にはいかないの?

    #スクリプト必須のサイト嫌い
    • 動的なページの内容変更についてそれをやろうと
      すると、動的なものはすべてサーバ側で処理
      しなくてはならず、はっきりいってまわりくどい
      ものになるでしょう。

      ですから、方法のひとつではあってもあまりさえた
      やりかたのようには思えません。

      ウィジェットの操作や入力を支援して
      くれるスクリプトは大歓迎。
      --

      - Ryuzi Kambe -
      親コメント
      • by Anonymous Coward
        入力を支援してくれるスクリプトって、どんな支援がありますか?

        ろくなものに出会ったことがないのですが。
        • by Ryuzi Kambe (38) on 2002年09月19日 2時02分 (#168446) ホームページ 日記
          例えば、Bugzilla(jp) [mozilla.gr.jp] の検索ページで使っているものは
          プログラムを選ぶとバージョンやコンポーネントを
          絞りこんでくれます。

          ほかには、固定長の記号の羅列をpasteすると
          複数のフォームに分離して入力コードに
          視認をしやすくしてくれるものだとかも
          気が聞いていてよいと思いました。

          フォーカスが他のウィジェットに移った時点で
          とりあえず今までに入力した値からわかる
          金額なり価なりの小計を表示してくれたりするものは、
          わりとそのへんにあると思います。
          --

          - Ryuzi Kambe -
          親コメント
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...