
GmailのセッションIDを自動的に盗むツールが登場 28
ストーリー by hayakawa
利用者の方はご注意を 部門より
利用者の方はご注意を 部門より
あるAnonymous Coward 曰く、
米ラスベガスで開催されたハッカーカンファレンスDefconで、GmailのセッションIDを自動的に盗むツールが発表された(hungry-hackers.com・本家記事)。
Gmailにアクセスする際にブラウザはクッキーを送信している。Gmail上の単なる画像にアクセスするだけでもクッキーは送られているのだが、Gmailはセッション情報をクッキーで管理しているため、悪意ある者がhttp://mail.google.comの画像をメールやウェブページに紛れ込ませることでセッションIDを得ることが可能である。一旦セッションIDを手に入れてしまえば、パスワード無しにログインすることが可能になる。
このツールは2週間後にリリースされる予定だが、Gmailには常にhttpsを利用する設定オプションが追加されているので、特に保護されていないワイヤレスネットワークからアクセスする際などは利用したほうがよいかもしれない。
保護されている/されてないは関係ない (スコア:1, 参考になる)
> 特に保護されていないワイヤレスネットワークからアクセスする際などは利用したほうがよいかもしれない。
今回の問題の場合、途中経路が保護されている/されてないは関係ない。常にhttps経由推奨になる。
# と思う。あってますか?>エロい人
理屈が判りません (スコア:1)
"悪意ある者がhttp://mail.google.comの画像をメールやウェブページに紛れ込ませることでセッションIDを得ること"
を回避できるように読めるのですが、この方面に聡い人なら周知の仕組みの説明が省略されているのでしょうか。
これを設定しておけば、セッションIDが送出される際は必ず暗号化されるということなのでしょうか。
また、保護されていないワイヤレスネットワークからの接続を行っている場合に推奨されている理由も不明です。
ブラウザの近辺だけでIPパケットを傍受できるという話でもないようですし。
Re:理屈が判りません (スコア:1)
ご両人、どうもありがとうございました (スコア:2, おもしろおかしい)
ので、gmailの設定にチェックを入れておくと、secureフラグを立てたcookieを使うようになるので、
https://www.google.co.jp/images/nav_logo3.png [google.co.jp]なんてしても大丈夫と……って、あれれ。
Re: (スコア:0)
> https://www.google.co.jp/images/nav_logo3.png [google.co.jp]なんてしても大丈夫と……って、あれれ。
その場合Cookieを伴った画像へのリクエストはhttpsな通信路を経由して送られるので、悪者には読み取れません。
>>> これを設定しておけば、セッションIDが送出される際は必ず暗号化される
わけです。
Re: (スコア:0)
これをOK押すような人だったら簡単にセッションID取れちゃうぞっと。
Re:ご両人、どうもありがとうございました (スコア:3, おもしろおかしい)
> 安全な接続ができませんでした
> www.google.co.jp は不正なセキュリティ証明書を使用しています。
> この証明書は www.google.com にだけ有効なものです。
> (エラーコード: ssl_error_bad_cert_domain)
> * サーバの設定に問題があるか、誰かが正規のサーバになりすましている可能性があります。
> * 以前は正常に接続できていた場合、この問題は恐らく一時的なものですので、後で再度試してみてください。
>
> 例外として扱うこともできます...
これのことですか (スコア:0)
「Cookieはセキュア・モードで」経済産業省がサイト運営者などに呼びかけ:ITpro [nikkeibp.co.jp]
5年前?日本は進んでますね。
Re:理屈が判りません (スコア:1, すばらしい洞察)
悪意ある者が〜のくだりですが、これはgmail.comへアクセスするパケットを盗聴すればセッションIDを盗めるということなのでしょうか?
それとも、悪意ある者がgmail.comへアクセスさせただけで、悪意ある者のウェブログか何かで盗めるということなのでしょうか?
たぶん前者だと思うんですが、肝心の部分がすっぽり抜けてる気が。
というか、パケット盗聴ならメール本文の盗聴のほうを気をつけるべきなんじゃ
Re:理屈が判りません (スコア:1)
Defconでのプレゼン [fscked.org](らしいもの)の14ページあたりによると、DNSキャッシュポイズニング [srad.jp]も駆使して、googole.com の DNS をハイジャックするようなことが書かれている。
というあたりを自動的にやっちゃうツールがリリースされる予定ってことなのかなぁ?
Re: (スコア:0)
Cookieのsecureフラグですかね(実際にそうなのか確認はしていません)。
> 保護されていないワイヤレスネットワークからの接続を行っている場合に推奨されている理由も不明
保護されていないワイヤレスネットワークは現実的に盗聴の危険性が高い [takagi-hiromitsu.jp]からだと思います。もちろん理論上は暗号化されていない通信経路はすべて盗聴されうるというのがSSLの前提なのですが。
常にhttpsを設定すると Gmail Notifier が使えなくなる (スコア:1)
http://www.google.co.jp/search?complete=1&hl=ja&q=gmail+notifier+https+%91%CE%89%9E&btnG=%8C%9F%8D%F5
Re:常にhttpsを設定すると Gmail Notifier が使えなくなる (スコア:2, 参考になる)
日本語環境でも、このパッチが使えるっぽい。
written by こうふう
Re: (スコア:0)
Googleの中の人ですか?
それとも、Yahooの中の人?
「Yahooでググれ!」って、結構、屈辱的だよねぇ
Gmailと何の関係が?SSLなしで経路途中で盗聴されたら情報は抜かれる (スコア:1, すばらしい洞察)
なんで今回問題視されるの?
タレ込み文をパっと読んだだけだと、他サーバーの画像へ送られたCookieやヘッダーなんかをその(呼び出し元)ページから取得できたのか、と思ってしまった。
もし経路途中で盗聴できるなら、ほんとクッキー盗まなくてもhttpでメールにアクセスさせて内容を取得できるよね。(今回はSSLオンリーにしてればこれも防げるけど)
Gmailの場合
http://mail.gmail.com にアクセス (セッション開始前だからセッションIDはない)
https にリダイレクト
認証、セッションIDを返す
以後、httpsだけでセッションID送信
ってことか。
言ってみれば、ログイン画面だけHTTPS使って通常ページはHTTPなすべてのサイトでは、セッションクッキー盗聴できますよってことでしょ。
Gmailだけの問題じゃない。(というかGmailはほぼ解決策を提示した)
そもそも、じゃあ、プレーンテキストで通信してるメールプロトコル(POP3)なんかだと、もうぜ~んぶ抜かれるわけですが、こちらはそんなに問題視されないのかな。まだまだPOP over SSLなんて使ってる人のほうが少ないでしょ。ここ見てる人は使ってるでしょうけど、初心者向けのISPメールなんかはだいたい通常のPOP3だ。
Re:Gmailと何の関係が?SSLなしで経路途中で盗聴されたら情報は抜かれる (スコア:1, すばらしい洞察)
gmailのセッションIDを自動的に盗むツールが2週間後にリリースされるので、
gmailを使っている人はgoogleが先週追加した「常にSSLを使うモード」を使うようにしましょう、
という話なのではないかと。
Re: (スコア:0)
gmailを使っている人はgoogleが先週追加した「常にSSLを使うモード」を使うようになってしまうので、
2週間後にリリースされるgmailのセッションIDを自動的に盗むツールを使うようにしましょう
と誤解した。
#Defcon的にたしかに情報は盗んで何ぼだよなと思うが・・。
Re: (スコア:0)
どちらかというと、gmailよりはリモートの画像を勝手に読み込むようなHTMLメール等々の対応ソフトは、メールのURLにIDなんかを混ぜておくと誰がどのメールをいつ読んだのかわかるので危険なのですが、今更そんなMUAもないですよね。ないといいんだけどな。
何も考えていない企業共がHTMLメール送ってくるので嫌になるよ。
Re: (スコア:0)
今さらこの程度で危険だなんてワロス (スコア:1)
別のPCで再認証した時点で元PCのセッション無効になるんのに、
セッションID抜かれたくらいで、認証回避されるなんて今時ザル過ぎる、、、
セッションIDとIPアドレスをセットで運用して、
IP アドレス変ったら、その都度、認証やり直せと、、、
プライベートIPとかProxy使ってると危険度増すけど、
グローバルIPで繋いでる限りは、
同一セグメントに攻撃者がいない限りたいして問題にならんだろ?
uxi
Re:今さらこの程度で危険だなんてワロス (スコア:1)
特殊な環境は (スコア:1)
ユーザー側で、IP変ったら再認証するかどうか、選択できれば問題ないかと。
# DHCP による更新が早い環境もあるでしょうし
uxi
Re: (スコア:0)
無茶言うな。君、Webアプリ開発やったことないだろ。
そんなことやったら、企業でProxy経由で使ってるユーザを見捨てることになるぞ。
基本中の基本だぞこんなのは。
auの糞システム [srad.jp]作ったのももしかして君みたいな連中か?
だからそれは特殊事例だと (スコア:1)
けど SSL なしじゃ元からセッションID丸見えなのに、IP非固定でどうやってセキュリティ保てと?
XSS とか画像リンクとか以前の問題だぜ?
auが糞かどうかは知らないが、仮に糞だとして、それはIPが固定できないユーザーへの配慮が抜けていた上に、オプション用意しなかったからだろ?
セキュリティ問題で、マイノリティに合わせて、マジョリティのレベルまで落とせってどっちが糞だよ?
そもそも企業で Proxy?
社内には関係ないだろ?
それとも社外の web アプリ使わす気?
しかも http でIP非固定のセッションIDで?
uxi
Re: (スコア:0)
これってsurfscanのこと? (スコア:0)
スニファも使えない中学生でも盗めて便利、と言う話?
そもそもPOPが… (スコア:0)