Hey Allen, Thanks for taking the time to document for this. Also cc'ing the specs list since it will require a change to the spec itself.
There is however still the case of someone setting up a rogue redirector specifically targeting OpenID which does the correct thing when the OP makes the request and then evil thing to the user when it sees a response. In any case, I'm in favor of adding this sort of mode to the protocol as it will help to de-mystify the return_to URL which right now is sort of this abstract thing which the user sees. Why do you see this as a better solution to the OP just fetching the return_to URL and not proceeding if it receives a 3xx code? How do you also see an OP dealing with an RP which is behind a firewall and thus cannot be reached? This would be one reason I'd lean toward the OP fetching the return_to URL, throwing a gigantic error if it is a 3xx and a decent warning on a 404, 500, or destination unreachable. --David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen Tom Sent: Monday, February 05, 2007 11:24 PM To: security@openid.net Subject: [security] Phishing issues with return_to url and realm Hello OpenID Security Community, This is my first post here, and before I get started, I'd like to compliment you all on the amazing progress that OpenID has made recently. As far as protocols go, this is very exciting, and I believe that it can be used as the foundation for as-yet unimagined new killerapps. However, there are some severe phishing issues with the OpenID 2.0 draft specification which urgently need to be resolved before the draft is finalized. First of all, anyone can craft valid Auth Requests using spoofed values for openid.return_to and openid.realm. This has very nasty consequences for sites running redirect servers for click tracking purposes, such as these: 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 A rogue RP could mask its identity and claim to be go.com or aol.com by hiding behind these redirect servers. When serving the Auth Request, an OP like myopenid.com will display this message to the user: "A site identifying as all sites matching http://anything.go.com has asked us for confirmation that xxxx is your identity URL..." This is EXTREMELY BAD, as users expect to trust their OP, especially if they feel extra secure because they configured an anti-phishing image (like MyOpenID's Personal Icon) and enabled SafeSignIn.This is particularly bad if the OP passes sensitive personal information or credentials via an extension in the Auth Response. The best way to resolve this issue is to define a way for the OP to verify that the return_to URL is actually a valid OpenID endpoint, and to also verify its association. I propose that an RP's return_to url expose an interface to allow it to identify itself as an OpenID 2.0 endpoint, and to also identify its association with the OP. Obviously, OPs must not follow redirects when interrogating the RP's endpoint. A possible interface would be for the RP return the its association handle if the OP hits the return_to url with the following parameters: openid.mode = "check_return_url" openid.server = "https://url_of_the_op.domain.com"; Instead of doing this on every Authentication Request, it would make sense for the OP to verify the RP as part of the association process. After the OP issues a shared secret and assoc_handle to the RP, the OP should be able to query the RP's return_to url before enabling the association, exactly the same way an RP can verify an Auth Response by querying the OP. Because this implies that an association should be tied to a given return_to url, the Association Request interface should be extended to require the return_to url. Once the OP has verified the return_to url, the OP can enable the association so that all incoming Auth Requests with that assoc_handle and return_to url can be served without requiring additional verification of the return_to url. Verifying that the return_to url is actually a valid OpenID endopoint prevents redirect servers from being used by phishers to spoof their identify. The additional step of tying an association with an RP's endpoint allows an OP a way to easily identify verified endpoints and realms, and allows a way for an RP to properly identify itself when making an Auth Request. I believe that resolving this issue would increase the level of trust that users place on their OPs, as currently, users cannot trust their OP to tell them what site they're logging into. My apologies for the long winded introductory mail. Comments and feedback would be very appreciated. Thanks, Allen _______________________________________________ security mailing list security@openid.net http://openid.net/mailman/listinfo/security _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
