【携帯/セキュリティ】ドコモ携帯の最新29機種、個人情報流出の恐れ [01/12]

>>23
封印を解いた結果がこれだよ！！w

単なるセッションハイジャックなら、トークンチェックぐらい付けとけとは思うが、
ググってもあんまり出てこないし、気持ち悪いな。

偽メール、勝手サイト接続で抜き放題だな。

さすが、ガラパゴスの大元ドコモだな(w

アップルとかは、全然問題ないしね。

javaなんて使ってる時点で負けだろ

旧機種使いは勝ち組だな

>>21
アドベぐらい俺だって読めるぜ

HOSTフィールドのチェックすらしてないCPがバカと言えばバカだけど、
やっぱiモードIDの実装にも根本的に問題あるわなぁ。

NetFront?

ＮＴＴドコモでは、公式サイトを運営する約３０００社には注意喚起したが、
それ以外の無数にある「勝手サイト」には「ジャバスクリプトの安全な利用はサイトを
作る側にとって基本的知識であり、具体的に説明はしていない」という。


これおかしいだろ？話を摩り替えてるな。

サイト運営者も大変だな。
ドコモから要求された仕様で作ったのに

>>22
■ドコモのお粗末対応まとめ

2009年5月19日
新機種に新しいｉモード機能（JavaScript）付けたから買えよ
http://k-tai.impress.co.jp/cda/article/news_toppage/45373.html
↓
2009年5月23日
なんか不具合多いから販売停止な
http://k-tai.impress.co.jp/cda/article/news_toppage/45452.html
http://k-tai.impress.co.jp/cda/article/news_toppage/45476.html
↓
2009年6月4日
やっぱ、その新機能（JavaScript）だけ使えないようにして再販するわｗ
1カ月程度でバグ修正できるから待ってろなｗ
http://k-tai.impress.co.jp/cda/article/news_toppage/45623.html
↓
そして5ヶ月後・・・
↓
2009年10月23日
新機能（JavaScript）をアップデートで使えるようにしてやるよ
http://k-tai.impress.co.jp/docs/news/20091023_324009.html
↓
2010年1月12日　　　　　　　　
最新２９機種ドコモ携帯、個人情報流出の恐れ
原因はやっぱりJavaScript　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　←←←イマココ　　　　　　　　　　
http://www.yomiuri.co.jp/national/news/20100112-OYT1T00842.htm

これって去年話題になったヤツだよね？
業者の宣伝なんだろうけど、
ぶっちゃけDNS Rebindingを使ってる時点で実現性が低すぎる。

そもそも携帯電話に限った話じゃないし（JavaScriptが動けばどこでも同じ）、
ID送信するくような場合は必ずダイアログが出るから（ただしソフトバンク除く）、
そう簡単にはデータは渡されないよ。

そもそも最初に「悪意のあるサイトに誘導する」ことが絶対に必要であるため、
公式サイトのユーザを誘導するのはほぼ無理だし、
仮に騙せたとしても一度ダイアログが出るからそれをOKしなければ良いだけ。
しかもサイト側は自由にできるドメインとPrimaryDNSサーバおよびRebinding対応のDNSソフトが必要だから、
苦労が大きいくせに足が付きやすくリスクが大きい。

去年話題になったときもそうだったけど、
「騙す労力が大きい割には実りの少ないもの」
と言う見解だったなあ。
大体DNS Rebindingなんて2007年の話題（のくせにPCブラウザでも特に対処されてない）だし。

>>18
JavaScriptから他のドメインの情報を読み取りできるのは
JavaScriptエンジンの実装がおかしいな。
CSSXSSに近いんじゃないか?

ただ、ドコモの「注意喚起した」ってのからするとXSSとかCSRFだから、
読売の記事が怪しい気もする。

どっちにしてもかんたんログインが事態をを悪化させてるな。

>>37
公式サイトからいけるんだなこれがｗ
公式サイトからの広告クリックで勘違いしてる間にいけてします。
それによる請求問題とかすでに出てたはずだ。

>37
確かにDNS Rebindingで本事象は発生しそうなんだけど、
XMLHttpRequestでguid=ONした時ってダイアログ出るの？

元ネタは、mpwブログの記事か？
http://mpw.jp/blog/

大丈夫かな　心配だよね

>>15
知ったか乙。さすが情強だなw

>>37
> ID送信するくような場合は必ずダイアログが出るから
でねーよバカ。

>>37
> 大体DNS Rebindingなんて2007年の話題
> （のくせにPCブラウザでも特に対処されてない）だし。
PCならcookie飛ばねーだろカス。

>>14
できちゃうっつーか、できるのがjavascriptの機能
問題はjavascriptじゃなくてIDだけで簡単に個人情報見れる仕様の方

IDと地名結び付けて地元の天気予報をすぐ見られるとかその程度にするのが常識
IDと名前住所メアドを結びつけるのはアホ

なるほど。。。
docomo側かソフトでDNS Rebindingに対応するのかなぁ。

>>45
どうやって対応するんだよw
DNS情報を書き換えてるのは悪意のあるドメイン管理者自身なのに。

>>20
つっこんだら負け

>>46
ドコモGWはDNS情報をキャッシュしていないらしい。
例えば、TTLも無視して無条件で5分キャッシュする仕組みにするとかね。

>>48
そこまでの傍若無人やるなら、中途半端にインターネットに足出すの止めて完全に
独立したネットワークにして欲しいわ＾＾;

ほんとはどうなの　問題ないの

>産業技術総合研究所情報セキュリティ研究センターの高木浩光主任研究員は、
>「利用者ＩＤがあらゆる携帯サイトに自動で送られ、認証に使われる仕組みは問題だ」
>と指摘している。

ここを見ると、認証に必要な情報が常にダダ漏れですよって指摘にも見えるんだよな。
Javascriptとか関係あるのか？

Javascriptが関係するとしたら、悪意のあるサイトにアクセスしたら、ショッピングサイトの
画面が開いて勝手に買い物されてたとか、そういう話かね。

Javascriptを使って個人情報を抜くってのが理解出来んのだよなぁ。
それが出来たら Javascriptの実装がおかしいだけじゃなくて、上のコメントにも繋がらない。

Javascriptと関係なく個人情報が危機に晒されてるって話と、Javascriptによるアタックに
弱いサイトがあるっていう話が混ざってる？

いろいろ出てくるもんだな　報道すると悪用されないか

>>51
根本的な問題はiモードIDでアカウントやセッションを識別する間抜けな作りの携帯サイトが存在することにある。
それだからこそXSSやDNS Rebindingによる攻撃が想定しうる。

いちいちパスワード入力を求めたり、クッキーによるセッション管理をしてればマシだったろうが
クッキー自体がiモード2.0じゃないと実装されてない。
ガラパゴスの末路だな。

>>51
iモードIDみたいな仕組みがあるのは日本だけなんだよ。
一方、Ajaxとかは世界標準。
世界標準の規格は、iモードIDみたいなのの存在を想定してないわけ。
そこで成り立ってるセキュリティなのに、
両方を融合したら、そりゃブッ飛ぶってわけ。

ガラケーｗ

>>36
ヒドスｗ

>>54
DNS Rebinding対策にHOSTフィールドチェック、なんて
世界標準の基本的なセキュリティ対策だと思うけど。
iモードIDがあるとよりヤバイってことで、
Ajaxにはセキュリティもへったくれも無いわな。

現実的に、TTL数秒とか有り得ないのを弾くだけでいいんじゃないか？

>>57
PCサイトではDNS rebinding対策は要らないよ。
要るのはIPアドレスでアクセス制限してるイントラサイトとかだけだから。

>>57
hostフィールドチェックって基本なの？しらんかったよ。
個人情報表示するようなページはhostチェックしろと。。。
というか全ページでやったほうが楽か。ふむ。

ドコモの、BeeTVってすごいな
月315円で見放題って書いてあるけど、実際には1番組を見ただけで、
上限の4410円のパケット代を請求される

朝気づいたら、勝手にダウンロードされてて、パケ代4410円だから

>>60
チェックつってもWebサーバの設定一行じゃないの。
デフォルトではされてないってだけで、よほどの素人じゃなきゃほぼ無意識にやってるかと。

>>59
ブラウザの仕様上DNS rebindingに対しては実質やらなくて大丈夫ってだけで、
HOSTフィールドチェックくらいは普通やるべきじゃない？
つかiモードブラウザもちょこっと仕様変えれば済む気がするけど、
DNSキャッシュの仕組みが皆無なんかな？

>>63
iモードの場合、DNSをひいているのは、ブラウザじゃなくて、ゲートウェイのプロキシじゃないかな。

安全の為に。利用者ＩＤは通知しないにした方がいいな

株屋乙

>>61
それが目的だし

すまん。教えて欲しい。
今回のdocomo端末に対しては、リクエストのhostフィールドが
正しいかどうかチェックすればよいって認識でOK？
そもそものDNS Rebindingの対策ってどうすればよいの？
PCとかの場合は、ブラウザ側やFlashとかが対応してるってこと？

>>68
>今回のdocomo端末に対しては、リクエストのhostフィールドが
>正しいかどうかチェックすればよいって認識でOK？

その通り。方法は2つある。次のどっちかでいい。a)がオススメ。

a) Apache の httpd.conf で name-based virtual hosts の設定をして、
自分とこのホスト名でしかアクセスできないようにする。
http://httpd.apache.org/docs/2.2/ja/vhosts/examples.html

b) iモードIDを使う処理で、HTTPリクエストのHost:フィールドが正しいか
を調べて、違っていたら処理を中止する。

>そもそものDNS Rebindingの対策ってどうすればよいの？
>PCとかの場合は、ブラウザ側やFlashとかが対応してるってこと？

PCの場合はiモードIDみたいなものがないので、この問題が起きない。

PCでも起きるDNS rebindingの問題は、比較的リスクが小さいと考えられ
ているため騒ぎにならない。影響を受けるのは、IPアドレスでアクセス制限
されているページが、間接的にアクセスされてしまうリスク。このため、
ブラウザやFlashが、DNS piningという対策を打っている。

>>69
即レスありがとう。助かった。
クライアントから説明求められてて確信が持てなかったので、、、

docomo用のWebサーバはApacheのVirtualHostで対応してみる。
サーバ全体で対応できるから前者がよいね。

PCの場合も理解。uid・iモードIDの概念がないから問題なしで、
通常のXSSやCSRFに対応すべく作ればいいってことかな。
(そもそもウチの会社はPCサイトは作ってないし)

>>70
>PCの場合も理解。uid・iモードIDの概念がないから問題なしで、
>通常のXSSやCSRFに対応すべく作ればいいってことかな。

IPアドレスでアクセス制限するようなサイトでなければ、YES。

ドコモは放置か

嗚呼・・・

いままでずっとジャワっていってきたけど違うのか

カレー？