[security] Phishing issues with return_to url and realm
atom at yahoo-inc.com
Mon Feb 5 23:23:50 PST 2007
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
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
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.
More information about the security