Discovery on the RPの本当の意味

OpenIDの2.0Finalで突然追加された仕様に、Discovery on the RPというものがあって、こいつ何してんの？といっつも思っていた。


で、昨日Apple Store, Ginzaでやったイベントのプレゼンテーションを作っていて、
それに触れなければならなかった。


そのとき触れた内容は、

• 認証応答が返る場所がRPとして妥当かをXRDSを見てチェックする
• EV-SSLなどエンドポイントの情報からユーザーへの警告に利用する

とかにしました。


でも、なんか納得いかないなーと思って、過去MLを調べてみたら、やっぱりあった。

MLを探ってみたところ、2007-2のsecurity@openid.netに投げられていたコメントを見つけた。
http://openid.net/pipermail/security/2007-February/000241.html

サマリは下記。
---
realmとreturn_toを共にspoofすることで、アサーションの検証はクリアしつつも、あさってのRP Endpointに認証応答をブラウザリダイレクトできるのは、クリックトレース用にリダイレクトを挟むようなページに対して問題だとある。

• http://x.go.com/cgi/x.pl?goto=http://www.jyte.com
• http://www.aol.com/ams/clickThruRedirect.adp?1,2,http://www.jyte.com
  

悪意のあるRPは、上記の例では、go.com/aol.comのふりをして、自身のIdentityを隠蔽すことができる。何を言っているかというと、通常のOPでは、「認証しますか？」画面に戻り先としてURIオーソリティー部分だけを表示するので、ユーザーにとっては"www.aol.com"に認証応答を返しているように見えるから。(実際にはリダイレクトされて、悪意のあるRPに情報がリダイレクトされるにも関わらず。)

---

・・・ということで、OPが直接RPのEndpointを検証する必要があるという論理展開。
これを強制すれば、OPが表示する認証要求元が、比較的正しい物になると言えると思う。

これって前提があって、「引数無しでreturn_to_urlにアクセスする」際、アクセス先は信頼性の置けるサイトなので、そこに悪意のある機能改修を入れることはないと思う。つまり、Redirectするサイトは信頼性の置ける由緒正しいサイトで、Redirect先は悪意のあるRPという前提。

リダイレクトするサイトが悪意のある場合は、spoofingしたreturn_to_urlも"aol.com"のような正しそうなものではなく、怪しげなURLになる気がしてる。


RP Discoveryで用意するXRDSの中に、最初からリダイレクトを介す偽装済みのURIが入っていたら、RP Discoveryしても偽装が成立するようにも聞こえますが、RPドメイン名との比較を同時に行ったり、Yadisが勝手にHTTP30xリダイレクトをFollowしないようにすればいいのかな。

Yadisの仕様をみた限りでは、Redirectを自前で解決してコンテンツを取りに行くとは書いていないので、しないと思っているんだけど。。。


以上。