水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > docomoケータイのDNS Rebinding問題、全国紙で報道

docomoケータイのDNS Rebinding問題、全国紙で報道

2010年1月13日(水曜日)

docomoケータイのDNS Rebinding問題、全国紙で報道

公開: 2010年1月18日16時0分頃

docomoのJSケータイがDNS Rebindingで「かんたんログイン」を突破される話ですが、読売新聞で今になって報道されたそうで。

スラッシュドットにも。

って、この見出しだとサイト側の「かんたんログイン」の仕組みに脆弱性があるように読めますが、実際に「脆弱」なのは携帯端末の側 (あるいはドコモのゲートウェイ側に) ですよね。端末側の問題と端末固有IDを使った認証との組み合わせで発生する問題で、どちらにも問題があるのでややこしいですが。

端末固有IDの問題としては、大きく以下の2つがあると思います。

多くのサイトは、アクセス元のIPアドレスがキャリアのものかどうかを確認することで詐称を防いでいます。それで確実に防げるのか、IPアドレスの情報自体が詐称されないか、といった問題点も議論されてきましたが、いちおうはこの方法が標準になっているものと思います。

そして端末側のDNS Rebindingの問題ですが、これは簡単に言うと「正規のサイトを攻撃者のドメインであるかのように誤認させる」という攻撃です。端末は「攻撃者のドメインにアクセスしているつもりで、実は正規サイトにアクセスしている」という状態になります。正規サイトのドメインのつもりが実は攻撃者のサイトだった……となると大変で、正規サイトのCookieを読み出されてしまいますが、この場合は逆なので、できることはそれなりに制限されています。攻撃者の発行したCookieを正規サイトに送出することはできても、その逆はできません。ですから普通、DNS Rebindingでは認証がかけられていないコンテンツしか読み取れません。主にlocalhostや、プライベートアドレス上のデータを読み取るような攻撃が考えられます。

……なのですが、これが「かんたんログイン」の問題点と組み合わさると、突如として猛威をふるいます。端末固有IDは、攻撃者のサイトにも正規サイトにも同じものが送られるわけですから、攻撃者のドメイン向けに送ったつもりのIDが正規サイトに送られると、それで認証を通ってしまうわけですね。

※ちなみに、あえてアプリケーション側で対策するのであれば Host: をチェックするということになりますが、HTTP/1.0 では Host: が必須ではないので、HTTP/1.0 でアクセスしてきた場合にコンテンツが表示できなくなる可能性があります。が、docomoに限って言えば Host: は必ず送られてくるらしいので、ひとまずはこの対策で問題ないようですね。

関連する話題: セキュリティ

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)友井町バスターズ (富士見ファンタジア文庫)

その他サイト