[OpenID] Yahoo hijacking?
atom at yahoo-inc.com
Fri Apr 18 18:46:22 PDT 2008
The user could have clicked on a random link sent to them via IM or mail
which immediately sent the user to the Yahoo OpenID screen. At this
point, the Yahoo OP is only able to see the return_to parameter, which
really could be anything. The user elected to not sign in to whatever
site that was claimed in the return_to, so we need to send them somewhere.
Again, the main point is that the return_to is not necessarily the site
that initiated the authentication request.
Max Metral wrote:
> What is the abuse vector here? I send my user to Yahoo with a valid
> OpenID request including return_url and I'm going to trick them when
> they click "no I don't want to login" into going to some other site?
> Why wouldn't I have just sent them there directly? Email can be
> deceiving, so I don't mean this to be snide, I'm just not sure what the
> attack we're protecting against is.
> I would expect you would send them to the return URL with an appropriate
> error or "non-success" state. I like to think of authentication as a
> function. I put some args on the stack, I call you, you return where I
> tell you with a result. The current behavior is like when I tell my
> kids to put away their plates and they go play Candyland.
> -----Original Message-----
> From: Allen Tom [mailto:atom at yahoo-inc.com]
> Sent: Friday, April 18, 2008 9:23 PM
> To: Max Metral; general at openid.net
> Subject: Re: [OpenID] Yahoo hijacking?
> Max Metral wrote:
>> Now I know that I'm overstating the real problem right now, but it's a
>> trajectory thing. In the Yahoo case, the words say "I do not want to
>> login" with a back arrow. That should not take me to www.yahoo.com.
> And where should we send the user? The openid.return_to value is not
> necessarily the referrer, and the user has already told us that they
> don't want to sign in.
> If OpenID was able to allow us to verify the referrer (meaning that the
> Authentication Requests were signed using a shared secret between the OP
> and the RP), then it would be safer to return the user back to the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the general