新生鳩丸掲示板♯

bakera.jp > 新生鳩丸掲示板♯ > スレッド内全記事表示 (記事 5674 からのスレッド)

スレッド内全記事表示 (記事 5674 からのスレッド)

[5674] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

徳丸浩 (2010年1月19日 7時26分)

DNS Rebindingを携帯電話端末ないし事業社のゲートウェイの側で対策するのは難しいのではないでしょうか。

まず、現在の携帯電話は、かならずゲートウェイ(Proxy)経由でインターネットアクセスするので、DNSの名前解決はゲートウェイ上で行われます。

一方、DNS Pinningを行うには、端末側のページ単位で行われなければならないのに対して、一台のゲートウェイで多数の端末を処理するので、ページ単位の処理を行うのはゲートウェイ側では難しいように思います。端末からProxyへの要求に、どのページに紐ついたリクエストかどうかを区別する識別子はないと思われるからです。

したがって、ゲートウェイ側でできることは、DNSのTTLの最低時間を長くすることくらいですが、いつかは必ずIPアドレスを切り替えなければならないため、たまたまそのタイミングにアクセスしていたユーザが攻撃の被害にあうことになります。

つまり、キャリアの端末ないし設備では、攻撃を受ける確率を低減することはできても、完全にリスクをゼロにすることはできないように思えます。特殊なProxyをプロトコルまで含めて設計すれば対策できるでしょうが、コストが掛かりすぎて現実的ではないのではないでしょうか。

[5675] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

ばけら (2010年1月20日 1時19分)

コメントありがとうございます。

私の理解が不足しているのかもしれまんが、ここが良く分かりませんでした。

>一方、DNS Pinningを行うには、端末側のページ単位で行われなければならないのに対して、

ドメイン単位での pinning では問題があるということでしょうか?

[5676] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

徳丸浩 (2010年1月20日 8時35分)

pinningというのは、ドメインに対応するIPアドレスが変更された場合に、その変更を一時保留することだと理解しています。しかし、いつまでも変更を保留することはできず、いつかは変更しなければなりません。変更のタイミングとして有効なのは、一つのページの単位とすることで、そこから呼び出されるJavaScriptやJavaアプレット、Flashコンテンツなどがドメインに対するIPアドレスが同一であることを保証することは、実装も現実敵で、かつ効果が見込めます。

一方、ゲートウェイからはページという単位は見えないので、ホスト名を単位として、IPアドレスの変更を一定時間保留することくらいしかできません。これは、短いTTLを長くすることに相当します。しかし、どれくらいTTLを長くすれば確実に安全という明確な閾値はなく、いつかはIPアドレスが変更されるとすると、その変更のタイミングでたまたまDNS Rebindingが成立するリスクは残るということです。TTLを長くすることは、DNS Rebindingの確率を下げることはできますがゼロにはできない、という言い方もできます。

うーん、元の説明からあまりかわっていませんね。図示できれば、少しは分かりやすくなると思うのですが、どうでしょうか。

[5677] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

徳丸浩 (2010年1月20日 9時16分)

>ドメイン単位での pinning では問題があるということでしょうか?

ドメイン単位ですと、マルチユーザを前提とすると、全ての人が安全なpinningというのは不可能な場合が出てくるか、いつまでたってもIPアドレスを変更できない場合が出てくると思います。

[5678] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

匿名 (2010年1月21日 6時39分)

「一台のゲートウェイで多数の端末を処理するので、ページ単位の処理を行う…」の「ページ」とは1つのHTTPリクエスト(同一TCPコネクション)という意味でしょうか?

そうだとすると、IPアドレスで通信をするので、FQDNに割り当てられたIPアドレスが変わっても影響無いので、「変更のタイミングとして有効なのは、一つのページの単位とすること」という表現が理解できません。

[5676]で「ドメイン」と「ホスト名」の表現はいずれも「FQDN」のことを指しているという理解で良いですか?

[5679] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

徳丸浩 (2010年1月21日 7時42分)

>[5676]で「ドメイン」と「ホスト名」の表現はいずれも「FQDN」のことを指しているという理解で良いですか?

はい。それで良いです。説明が悪くてすいません。具体例で説明します。

http://example.jp/a.htmlから、XMLHttpRequestによりa001.xml、a002.xml、a003.xmlを呼び出すとします。同様に、/b.htmlからb001.xml…b003.xml、/c.htmlから、c001.xml…c003.xmlを呼ぶと仮定します。以下では、a.htmlからb.htmlに遷移する状況でIPアドレスを変更するタイミングが来た状況を使って説明します。

このようなサイトで、exmaple.jpに割り当てられたIPアドレスを「変更して良い」タイミングは、a.htmlからb.htmlに遷移した瞬間(b.htmlのリクエストを処理する瞬間)です。a.htmlのリクエストからa001.xml…a003.xmlを呼び出すタイミングや、b.htmlからb001.xml…b003.xmlを呼び出すタイミングで変更を許すと、DNS Rebindingが発生します。

しかし、ゲートウェイ(PROXY)では、この「FQDNに割り当てられたIPアドレスを変更して良いタイミング」が分かりません。

さらに、マルチユーザを想定すると、ユーザ毎(端末毎)に「FQDNに割り当てられたIPアドレスを変更して良いタイミング」は異なることになります。

通常のPROXYには、そのような複雑な機能はないと認識しています。それができるのは、ブラウザが名前解決をしている場合です。携帯電話の場合は、ゲートウェイが名前解決をしているので、DNS Pinningはできないと考えます。

[5680] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

匿名 (2010年1月21日 10時7分)

ご説明ありがとうございます。よく理解できました。

仰るとおり、ゲートウエイ側のTTLを長くすることが、良いリスク低減策だと思います。

[5681] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

ばけら (2010年1月22日 19時51分)

ありがとうございます。理解できたような気がします。「ページ単位」というのは範囲の話というより、時間の話ということですね。

pinningしている時間を、

「名前解決が行われてから、次のページ遷移が行われるまでの間」

とする感じでしょうか。

ふと思ったのですが、普通のWebブラウザなどではどういう処理になっているのでしょう……?

iframeでの遷移なども考えられるので、単に「ページ単位」の処理ではうまくいかないケースもありそうに思うのですが。

[5682] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

えむけい (2010年1月23日 2時21分)

>ふと思ったのですが、普通のWebブラウザなどではどういう処理になっているのでしょう……?

>iframeでの遷移なども考えられるので、単に「ページ単位」の処理ではうまくいかないケースもありそうに思うのですが。

ブラウザはページがiframe内に読み込まれているかどうかを判別できますし、サードパーティーCookieの判定などのために実際に判別していますが、ゲートウェイはそうではありません。

ゲートウェイでの対応が困難なのは、正しく判別するにはゲートウェイの知り得ない情報が必要だからだということです。

[5683] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

ばけら (2010年1月24日 3時17分)

>>iframeでの遷移なども考えられるので、単に「ページ単位」の処理ではうまくいかないケースもありそうに思うのですが。

>ブラウザはページがiframe内に読み込まれているかどうかを判別できます

 実際にiframe内での遷移はどう扱われるのでしょうか?

 たとえば、

・あるページにiframeが2つあって、同じコンテンツを読み込んでいる

・うち、片方のみで遷移が起こった

 という状況のとき、遷移していないほうは従前の情報をpinningし続け、遷移した方は破棄することになるのでしょうか。

 それはそれで想定外のことが起きそうな気もするのですが……。

[5684] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

えむけい (2010年1月24日 21時54分)

iframe内での遷移かどうかは判別していますが、pinを保持するかどうかの判定には用いていないようです。単にDNSのTTLを無視して一定期間名前解決の結果を保持しているだけです。

そもそも固有IDを用いていないPC用Webブラウザでは完璧に対策する必要がないからでしょうか。

> 遷移した方は破棄する

遷移のタイミングで無条件に破棄するのは問題ありませんか? 「少なくとも遷移するまで破棄しない」ならともかく。

[5685] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

徳丸浩 (2010年1月25日 8時15分)

>そもそも固有IDを用いていないPC用Webブラウザでは完璧に対策する必要がないからでしょうか。

そうですはないですか?ローカルネットワークに対する攻撃は、LAN側のDNSキャッシュサーバーで対策する、インターネット側のサーバーは元々問題はおきにくいからということで。

奥一穂さんの以下のエントリが参考になると思います。

http://labs.cybozu.co.jp/blog/kazuho/archives/2007/11/djbdns_and_anti-dns_pinning.php

http://b.hatena.ne.jp/kazuhooku/20071112#bookmark-6474799

[5700] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

fdgafgaf (2010年2月11日 2時41分)

>ありがとうございます。理解できたような気がします。「ページ単位」というのは範囲の話というより、時間の話ということですね。

>pinningしている時間を、

>「名前解決が行われてから、次のページ遷移が行われるまでの間」

>とする感じでしょうか。

>

>ふと思ったのですが、普通のWebブラウザなどではどういう処理になっているのでしょう……?

>iframeでの遷移なども考えられるので、単に「ページ単位」の処理ではうまくいかないケースもありそうに思うのですが。

dfga

[5701] Re:「docomoケータイのDNS Rebinding問題、全国紙で報道」

fdgafgaf (2010年2月11日 2時44分)

>ありがとうございます。理解できたような気がします。「ページ単位」というのは範囲の話というより、時間の話ということですね。

>pinningしている時間を、

>「名前解決が行われてから、次のページ遷移が行われるまでの間」

>とする感じでしょうか。

>

>ふと思ったのですが、普通のWebブラウザなどではどういう処理になっているのでしょう……?

>iframeでの遷移なども考えられるので、単に「ページ単位」の処理ではうまくいかないケースもありそうに思うのですが。

dfga

[5787] 未承認メッセージ (投稿元:58.247.163.24)

美人豹 (2010年4月21日 23時41分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5791] 未承認メッセージ (投稿元:58.38.80.209)

ugg サンダル (2010年4月24日 3時13分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5794] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月24日 21時19分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5795] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月24日 21時50分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5796] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月24日 21時51分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5797] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月24日 21時52分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5798] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月24日 21時53分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5799] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月24日 21時54分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5800] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月25日 3時28分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5804] 未承認メッセージ (投稿元:58.38.91.8)

ugg サンダル (2010年4月27日 1時7分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5805] 未承認メッセージ (投稿元:112.64.17.4)

kokol (2010年4月27日 2時30分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5806] 未承認メッセージ (投稿元:112.64.17.4)

lopo (2010年4月27日 2時31分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5807] 未承認メッセージ (投稿元:222.64.97.47)

ugg サンダル (2010年4月27日 20時12分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5810] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月28日 22時26分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5811] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月28日 23時13分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5812] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年4月29日 3時35分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5818] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年5月11日 23時8分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5823] 未承認メッセージ (投稿元:222.188.0.253)

抨蛊 (2010年5月12日 21時40分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[5907] 未承認メッセージ (投稿元:112.64.16.186)

山田 美邦 (2010年8月4日 2時53分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[6136] 未承認メッセージ (投稿元:58.246.255.162)

yjuyjtyjt (2010年9月28日 21時52分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[6374] 未承認メッセージ (投稿元:112.64.16.72)

VigRX (2011年1月19日 3時7分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

[6966] 未承認メッセージ (投稿元:126.15.0.182)

レイバン (2011年11月16日 2時56分)

(この記事は承認されていないため、管理者が許可するまで公開されません。)

最近の日記

関わった本など