OpenID Provider のセキュリティ対策 (2) - return_to と realm のチェックを怠るな!
OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入!話はそれからだ - Yet Another Hackadelicの続編です。
はじめに
RP が認証アサーションリクエストである checkid_setup/checkid_immediate を行う際には通常は return_to と realm を指定します。
return_to とは
OP から認証アサーションレスポンスを間接通信で受け取る際に戻って来るURLの事。RP が指定しておく。
realm とは
return_to のパターンをワイルドカードを使って表現する。
return_to と realm の検証
基本的に return_to の先は http://openid.art-code.org/handler であるという前提で。便宜上番号振りました。
(1) 期待通りの組合せ
みたいな組合せの場合、realmで指定したパターンにreturn_toはマッチするので特に問題は無い。
(2) realm の指定がワイルドすぎる
- realm
- http://*.org
- return_to
- http://redirect.example.com/redirect?url=openid.art-code.org/handler
かなり広範囲にワイルドカードが指定してあるケース。これはダメ。
(3) realm に違反する return_to
例えば、
- realm
- http://*.art-code.org
- return_to
- http://redirect.example.com/redirect?url=openid.art-code.org/handler
これは反してるのでNGになるはず。
(4) realm/return_to は正常だがRPとは異なるホストに適用してある
さらに言うと、
- realm
- http://*.example.com/
- return_to
- http://redirect.example.com/redirect?url=openid.art-code.org/handler
だったら見かけ上OKだけど、普通に考えてOPとしてこれを許可する訳には行かない。
そもそも RP から見てまったく違うホストに対して realm も return_to も指定してあるので、こういうケースは信じるべきではない。
国内OPの対応状況
○は良く出来ました。×はダメ。△は微妙。解説はこの後で。
-- | Yahoo! Japan | livedoor | hatena | wassr | openid.ne.jp | ||||||
(1) | ○ | ○ | × | × | × | ||||||
(2) | ○ | × | × | × | × | ||||||
(3) | ○ | △ | △ | △ | ○ | ||||||
(4) | △ | △ | × | × | × |
Yahoo! Japan の場合
(2) の場合 -> ○
こんな感じで怒られた。これがあるべき姿。さすが Yahoo! ですな。一点だけ言えば openid.mode=error で返してもいい気がするけど、敢えて返さないようにしたんですかね。
(3) の場合 -> ○
(2) と同じ画面で怒られる。これも正しい。間接通信でレスポンスが戻ってこないのも (2) と一緒。
(4) の場合 -> △
これは正常であると認められてリダイレクタに飛ばされます。この議論は別途。