[PR]小規模ECサイトに最適なWAF、SiteGuard Lite
徳丸浩の日記
2010年02月12日 DNSリバインディング
_かんたんログイン手法の脆弱性に対する責任は誰にあるのか
id:ikepyonの日記経由で、NTTドコモのサイトに以下のセキュリティ・ガイドラインが掲示されていることを知った。
iモードブラウザ機能の多様化により、機種によってiモードサイトにおいてもJavaScriptを組み込んだ多様な表現、CookieやReferer情報を有効に活用したサイト構築が行えるようになりました。
しかし、PC向けインターネットサイト同様に、セキュリティ対策が十分に行われていないサイトでは、そのサーバの脆弱性を突き(クロスサイトスクリプティング、SQLインジェクション、DNSリバインディングなど様々な攻撃手法が存在しています)、これらの機能が悪用される危険性があります。十分にご注意ください。
[作ろうiモード:iモードブラウザ | サービス・機能 | NTTドコモより引用]
XSSやSQLインジェクションと並んで、DNSリバインディングというマニアックな手法が紹介されていることは驚きだが、おそらく私が昨年発表したiモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性のことを指しているのであろう。
しかし、引用部の表現には違和感がある。DNSリバインディング自体は既知の攻撃手法であるが、「PC向けインターネットサイト」に対する攻撃ではなく、インターネットサイトを閲覧しているPC自身やファイアウォールの内側のローカルネットワーク上の端末に対する攻撃手法として知られている。このあたりの解説については、ここやここを参照頂きたい。
しかも、先のセキュリティ・ガイドラインには、これら脆弱性についての説明はなく、「十分にご注意ください」とあるだけで、参考情報としてはIPAのトップページが紹介されている。
なお、セキュリティ対策情報については、「独立行政法人 情報処理推進機構」(IPA)が公開する情報なども参考にしてください。
[作ろうiモード:iモードブラウザ | サービス・機能 | NTTドコモより引用]
IPAにDNSリバインディングの解説があったかなと疑問に思い、「DNS "リバインディング" site:ipa.go.jp」や「DNS rebinding site:ipa.go.jp」などのキーワードで検索してみたが、ヒットしない。ひょっとしたらどこかに存在する可能性はあるが、リンクもなく、サーチでも引っかからないのでは、ないのと同じだ。これでは、単に危険があるから注意しろと言っているだけで、解決策を示していないことになる。
このような状況から、この文書は次のような意図をもって書かれたのではないかという感想を持った。
- 同DNSリバインディングの問題は、携帯端末や事業者設備の問題ではなく、Webアプリケーション側の問題である(
私も同意追記参照) - NTTドコモは、かんたんログインのDNSリバインディング脆弱性を、PCも含め昔から存在していた問題と印象づけたいのではないか(実際は違う)
- DNSリバインディングの解決方法を明確にリンクしなかったのは、「NTTドコモ公認の解決策」という印象を与えることを避けたかったからではないか
- 一方で、DNSリバインディングに対する注意喚起を行ったという実績は作りたいのではないか
「実績作り」で思い浮かぶのは、Yomiuri Onlineにも掲載された以下の記事だ。この記事は、かんたんログインのDNSリバインディング脆弱性に関して、NTTドコモのコメントを掲載している。
NTTドコモでは、公式サイトを運営する約3000社には注意喚起したが、それ以外の無数にある「勝手サイト」には「ジャバスクリプトの安全な利用はサイトを作る側にとって基本的知識であり、具体的に説明はしていない」という。
[ドコモ携帯、情報流出の恐れ…最新29機種より引用]
勝手サイトに対して従来説明していなかったので、新たに説明したということなのかもしれない。しかし、先の説明ではまったく不十分だ
NTTドコモ(および他の携帯電話事業者)は、かんたんログインのセキュリティ問題について、そろそろ態度を明確にする必要があるのではないだろうか。その態度とは、以下の選択肢のどれを選ぶのかということだ。
- かんたんログインという手法は各サイトが独自に実装しているもので、携帯電話事業者はガイドラインなども提示していないので責任は一切負わない
- かんたんログインは、携帯電話事業者が提供している端末固有IDの応用であるので、安全な使い方を示すなど携帯電話事業者としても一定の責任が生じる
くだんの「セキュリティ・ガイドライン」を読む限り、NTTドコモは(本音では)事業者として一切責任を負わないと姿勢なのだと想像する。しかし、そう明言すると反発も予想されることから、あいまいな態度をとっているように見うけられる。
しかし、このようなあいまいな状況がもっとも危険なのだ。かんたんログインがこれだけ普及した現在でも、この手法に対する責任がどこにあるのか、非常に不明確な状態が続いている。最終的には、Webサイトの運営者が責任を負うべき問題ではあるだろうが、中小零細企業が多いケータイサイトの運営者がそのような問題意識を持っているとは考えにくいし、DNSリバインディングを含む複雑なセキュリティ問題を独自に研究・解決する能力もないだろう。であれば、日本独自の進化を遂げた携帯電話コンテンツのセキュリティ問題に対して、もっと広い枠組みでの検討が行われる必要があるし、そこにもっとも近い位置にいるのが携帯電話事業者であると私は考える。
追記(2010/2/16)
括弧内で「私も同意」と書いた部分について指摘を頂戴しました。
ここは同意しちゃだめ。Webアプリ側は「対策可能」なのであって、元からそこに問題があるわけじゃない。
[HiromitsuTakagiのブックマーク / 2010年2月15日 (3)より引用]
少なくともWebアプリケーション側の「不具合」ではないように思いますし、実際のところはこんな感じではないでしょうか。
- iモードブラウザ2.0対応のdocomo端末は、DNS Rebindingの攻撃に対して脆弱である。
- 端末の問題であるため端末側で対応することが望ましいが、名前解決はdocomoのゲートウェイ側で行われる場合があり、端末側では対応が難しい。
- docomoのゲートウェイの問題についてはdocomo側で対応することが望ましいが、問題の性質上、対応が難しい (参考: Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」)。
- これらの問題に対してはWebサイト側で対応することが可能であり、しかも簡単に対応できる方法が存在する。
- 従って、Webサイト側での対応が推奨される。
[DNS Rebinding問題の所在 | 水無月ばけらのえび日記より引用]
まことに指摘の通りで、私の本意は、ばけらさんがわかりやすく要約していただいたとおりです。
したがって、携帯電話事業者はこの問題に対して免責されるわけではなく実施可能な対策はとるべきであり、具体的には、iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性に書いたように、DNSキャッシュの最短TTLを長くする程度の対策はとるべきだと考えます。
追記(2010/2/22)
かんたんログインのDNS Rebinding脆弱性の実例として、「ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された」を書きましたのでご参照ください。
- https://www.google.co.jp/ ×176
- http://takagi-hiromitsu.jp/diary/20100221.html ×86
- http://www.tokumaru.org/ ×12
- http://bakera.jp/ebi/topic/4054 ×5
- http://takagi-hiromitsu.jp/diary/201002.html ×5
- https://www.google.com/ ×4
- http://kjunichi.cocolog-nifty.com/misc/ ×2
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&... ×1
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&... ×1
- https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&... ×1
- http://www.askapache.com/ ×1
- http://search.fenrir-inc.com/?q=DNS docomo&hl=ja&s... ×1
- yomiuri online 名前解決 プロキシ ×1 / ipa dnsバインディング ×1 / 簡単ログイン ゲートウェイ i-modeサイト ×1 / 簡単ログイン 問題 ×1 / かざしてログオン 脆弱性 ×1
[PR]小規模ECサイトに最適なWAF、SiteGuard Lite
HASHコンサルティング株式会社
最近の記事
- 2011年08月30日
- 1. RSSフィードをリダイレクトします
- 2011年07月01日
- 1.
- 2011年03月29日
- 1. PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因
- 2011年03月22日
- 1. PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合(脆弱性)あり
- 2011年01月27日
- 1. CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
- 2011年01月04日
- 1. escapeshellcmdの危険な実例
- 2011年01月01日
- 1. PHPのescapeshellcmdの危険性
- 2010年10月03日
- 1. 問題点の概要
- 2010年09月27日
- 1. 文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
- 2010年07月25日
- 1. ツッコミSPAM対策で、ツッコミ抜きのRSSフィードを用意しました
- 2010年07月01日
- 1. ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
- 2010年04月06日
- 1. PROXY(プロキシ)経由でのDNSリバインディングと対策
- 2010年04月05日
- 1. JavaアプレットのDNSリバインディングはJRE側で対策済みだった
- 2010年03月29日
- 1. DNSリバインディングによる無線LANパスフレーズの読み出しに成功
- 2010年03月25日
- 1. DNSリバインディングによるルータへの侵入実験
- 2010年02月22日
- 1. ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された
- 2010年02月12日
- 1. かんたんログイン手法の脆弱性に対する責任は誰にあるのか
- 2010年01月18日
- 1. iモードブラウザ2.0のXMLHttpRequestでPOSTデータの扱いが困難になった
- 2009年10月19日
- 1. quoteメソッドの数値データ対応を検証する
- 2009年10月14日
- 1. htmlspecialchars/htmlentitiesはBMP外の文字を正しく扱えない
- 2009年10月09日
- 1. htmlspecialcharsのShift_JISチェック漏れによるXSS回避策
- 2009年09月30日
- 1. htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか
- 2009年09月24日
- 1. SQLの暗黙の型変換はワナがいっぱい
- 2009年09月18日
- 1. 文字エンコーディングバリデーションは自動化が望ましい
- 2009年09月14日
- 1. 既にあたり前になりつつある文字エンコーディングバリデーション
- 2009年08月05日
- 1. 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性
- 2009年03月28日
- 1. IPAは脆弱性の呼び方を統一して欲しい
- 2009年03月27日
- 2009年03月11日
- 1. U+00A5を用いたXSSの可能性
- 2008年12月22日
- 1. JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性