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, 参考になる)
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, 参考になる)
掲示板だけじゃなくて、CGI では結構そういうチェックの入ってるのが見られる。
Re:対処法 (スコア:2, 参考になる)
確かに、ここがイタイところですね。
ここに不都合がある人は、当面、
(3) HTTP referer を削除するproxyソフトを利用する。
(4) javascript の実行を禁止する。
のどちらかで、対処するしかないかも。
(今回の件に関わらず、javascriptは止められる限り止めといた方がヨサゲですし)
私自身は、前からRefererは止めてますが、あまり不都合は感じていません。
たぶん、幸せな環境で生きているのでしょう。(^^;
Refererチェックの有る業務用の掲示板は、どうせIE専用ですし・・・。(ToT)
--- Melloques Les Covdrasey ---
Re:対処法 (スコア:1)
>> (3) HTTP referer を削除するproxyソフトを利用する。
Referer が行かなくなるのは同じじゃないの?
Re:対処法 (スコア:1)
> Referer が行かなくなるのは同じじゃないの?
うわっ、ホントだ(笑)
気をつけたつもりだったのに、コピペのときに消し忘れました。
すみません。脳内削除しておいて下さい。m(_ _)m
--- Melloques Les Covdrasey ---
Re:対処法 (スコア:0)
選択的に行くように/行かないようにすることは容易です
proxyの種類によりますけど
そのような機能がなくてもアレゲ掲示板の住人なら
数分でハック完了でしょう :-)
Re:対処法 (スコア:0)
元々の問題も数時間くらいでハック完了しないの?
# できないので,というより正確にはやろうとしないので AC
Re:対処法 (スコア:0)
> 元々の問題も数時間くらいでハック完了しないの?
だから"本気でやらんかゴルァ"とのお怒りのあと、あっという間にpatchが出来上がってます。
see Bugzilla bug 145579 [mozilla.org].
Re:対処法 (スコア:0)
Re:対処法 (スコア:0)
# 今mozilla実行できる環境にいないのでAC
Re:対処法 (スコア:2, 参考になる)
squid の項を見ればそのものずばりがあります。
それだけでなく、多くの proxy と ブラウザでの対処方法が
まとまって書かれているので一読をおすすめします。
$ set -o vi
phoenixも対象かと (スコア:3, 参考になる)
修正希望? (スコア:0)
そこにないという事は「phoenixには問題がない」と
読めてしまいます。
・・・実際問題なかったりして。今手元にないので誰か確認希望。
Re:修正希望? (スコア:2, 参考になる)
Re:修正希望? (スコア:1)
別ウィンドウ/別タブなら大丈夫? (スコア:2, 興味深い)
URL直打ち/Bookmark選択は新しいウィンドウ/タブから行うということにしておけば、当座はしのげると考えていいのかな?
Re:別ウィンドウ/別タブなら大丈夫? (スコア:1)
で、一応マジレスしておくと、この形態で漏洩が起こらないのはページをunloadするという操作が発生しないのだから当然だと思われます。同一画面内で遷移が発生する場合にunloadの瞬間と次のurlへのジャンプがワンアクションとして発生するので漏洩しているのでしょう。
苦手な英語を必死こいて読む。 (スコア:1)
user.js 作ってやらねばいかんと言う事で宜しいのでしょうか?
最近 Mozilla しか使ってないので,こんな場合一寸だけ不安(^_^;
Re:苦手な英語を必死こいて読む。 (スコア:5, 参考になる)
大まかにいうと、
Re:苦手な英語を必死こいて読む。 (スコア:0)
少し遅くない? (スコア:0)
2002/09/04に気がついて直してるけども
# どれで、気がついたか覚えてない..AC
Re:少し遅くない? (スコア:1)
Re:少し遅くない? (スコア:1)
では
と表示されるようになりました。直ったようです。
翻訳 (スコア:0)
registered=xxxxxx;とか UID=xxxxxxxxxxxxxxxx;とか NGUserID=xxxxxxxxx-xxxxxx-xxxxxxxxxxx-xx;
とか出てしまうんですが、私だけでしょうか?
#なんだか良く分かりませんのでAC。(xox;
Re:翻訳 (スコア:0)
Excite Chatもそうなっています :)
Re:翻訳 (スコア:0)
Cookieをそのまま表示することになってるのか、
Excite翻訳のCookieがそのまま表示されているだけでした。
セキュリティには関係ないと思われるので激しくオフトピックです。
失礼しました。
移動ページのURLが知られるだけなの? (スコア:0)
具体的には,どんな困ったことが起こり得るんでしょうか?うまいことやるとクレジットカードの番号盗まれたりとかもあり得るのかな?(webで買物してないから,個人的にはそれもあまり心配じゃないけど)識者の解説をお願いします.
Re:移動ページのURLが知られるだけなの? (スコア:1)
確かにプライバシーが犯されるという意味では問題有るかも。
人によりますが。
これって昔IEでもよくあったリファ漏れってやつと同じかな?
Re:移動ページのURLが知られるだけなの? (スコア:1, 参考になる)
Re:移動ページのURLが知られるだけなの? (スコア:0)
「逆ですね」という指摘は正しいですよ。
逆という指摘が間違っていると勘違いしているモデレータがつけたのですか?
そういう観点でモデレートしちゃいけないよ。
やっぱりこういう行為を助長する「余計なもの」という誤訳は直した方がいいね。
Re:移動ページのURLが知られるだけなの? (スコア:1)
http://osdn.jp/tracker/index.php?func=detail&aid=42&group_id=4&atid=101
に意見してみるべし。
"Quidquid latine dictum sit, altum videtur."
Re:移動ページのURLが知られるだけなの? (スコア:1)
Re:移動ページのURLが知られるだけなの? (スコア:1)
判りやすいご指摘ありがとうございました。
Re:移動ページのURLが知られるだけなの? (スコア:0)
# この危険性については雑誌やMLを通じて度々言及されています。
株式会社@@@の開発した某サイトなんてユーザーIDとパスワードが生でGETメソッドで
Re:移動ページのURLが知られるだけなの? (スコア:2)
Re:移動ページのURLが知られるだけなの? (スコア:2)
実演ページで試してみたところ、「このリンク」のURLではなく、その直後にリダイレクトされるURL(http://srad.jp/index.pl)が、実演サイトに表示されました。というわけで、上の危険性は取消しです。
Re:移動ページのURLが知られるだけなの? (スコア:0)
移動先URLが知られるのではなくて、移動元URLが移動先に知られるのです。
Re:移動ページのURLが知られるだけなの? (スコア:0)
違います。
それでは、ブラウザの出す環境変数「HTTP_REFERER」の値を取得した場合と変わりがなく、敢えて今回問題として取り上げられるはずもないと思います。
タレコミ文を読んでの通りですが、該当バグの表題には、
「Web
Re:移動ページのURLが知られるだけなの? (スコア:2, 参考になる)
>> 違います。
>> それでは、ブラウザの出す環境変数「HTTP_REFERER」の値を取得した場合と変わりがなく、
HTTP_REFERER の値は、すべての移動元ではなく、
1. アンカーをたどって移動した元のページ
2. img src= で CGI を起動した元のページ
3. frame を指定して表示した親ウインドウ/フレーム
4. form で CGI を起動した元のページ
を通知します。そうでない実装もあったようですが不正な動作です。
Re:移動ページのURLが知られるだけなの? (スコア:0)
img src= に記述されたURIがCGIを利用したものであるか否かは
ブラウザーにとって知る由も無いことです。
たとえ判断するブラウザーがあったとしても
CGIならRefererを送りCGIでなければ送らないブラウザーがあるのでしょうか?
> 4. form で
Re:移動ページのURLが知られるだけなの? (スコア:1)
CGI でなければ送らないとは書いていません。確かに通常ファイルを指していても送られますが、それで悪用されるというのは考えにくいので、本トピックに関する限り注目する必要性を感じません。
>> > そうでない実装もあったようですが不正な動作です。
>> 不正な動作だと判断する理由がありません
「不正な動作」は、すべての移動元を通知するという動作を指すつもりでした。
Re:移動ページのURLが知られるだけなの? (スコア:1, すばらしい洞察)
> >> 不正な動作だと判断する理由がありません
>
> 「不正な動作」は、すべての移動元を通知するという動作を指すつもりでした。
そのことは伝わっております。
ですから、「すべての移動元を通知するという動作」すなわち「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でないからといって安心する心構えは機器管理の観点でいえば問題ありです。
Re:移動ページのURLが知られるだけなの? (スコア:0)
ブラウザーは環境変数「HTTP_REFERER」なんて出しません。
ブラウザーそのものに存在するセキュリティーホールについて言及するならば、ブラウザーそのものがどのように動作すべきで、それが現状どのように動作しているのかを正確に掴むべきです。
Re:移動ページのURLが知られるだけなの? (スコア:0)
>> ブラウザの出す環境変数「HTTP_REFERER」の値
> ブラウザーは環境変数「HTTP_REFERER」なんて出しません。
環境変数「HTTP_REFERER」を出すとはいっていません。
誤解を招く表現(もしくは正確でない?)であることは認めます。
> ブラウザーそのものに存在するセキュリティーホ
Re:移動ページのURLが知られるだけなの? (スコア:0)
さえたやりかた (スコア:0)
ブラウザは見るだけのソフトってことにして
JAVAだのスクリプトだのあやしいことはクライアント側で一切しない
って訳にはいかないの?
#スクリプト必須のサイト嫌い
Re:さえたやりかた (スコア:1)
すると、動的なものはすべてサーバ側で処理
しなくてはならず、はっきりいってまわりくどい
ものになるでしょう。
ですから、方法のひとつではあってもあまりさえた
やりかたのようには思えません。
ウィジェットの操作や入力を支援して
くれるスクリプトは大歓迎。
- Ryuzi Kambe -
Re:さえたやりかた (スコア:0)
ろくなものに出会ったことがないのですが。
Re:さえたやりかた (スコア:2, 参考になる)
プログラムを選ぶとバージョンやコンポーネントを
絞りこんでくれます。
ほかには、固定長の記号の羅列をpasteすると
複数のフォームに分離して入力コードに
視認をしやすくしてくれるものだとかも
気が聞いていてよいと思いました。
フォーカスが他のウィジェットに移った時点で
とりあえず今までに入力した値からわかる
金額なり価なりの小計を表示してくれたりするものは、
わりとそのへんにあると思います。
- Ryuzi Kambe -
Re:!? (スコア:1)
>何なの?どういうこと?
知らないうちに危険なコードを実行されるのに比べれば、深刻なものではないから。
決して今回の脆弱性がどうでもいいものというわけではないけど。
脆弱性の内容を理解せずにつっこんでいる時点で脊髄反射だぞ。
うじゃうじゃ