水無月ばけらのえび日記

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>[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はできないと考えます。

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

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

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

pinningしている時間を、

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

とする感じでしょうか。

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

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

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

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

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

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

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

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

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

　たとえば、

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

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

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

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

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

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

> 遷移した方は破棄する

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

>そもそも固有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

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

>pinningしている時間を、

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

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

>

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

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

dfga

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

>pinningしている時間を、

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

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

>

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

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

dfga