[security] Phishing issues with return_to url and realm

Allen Tom atom at yahoo-inc.com
Fri Feb 9 01:03:02 UTC 2007


Hi Johnny,

If the OP verifies the return_to by following all redirects until 
reaching the destination, then an evil RP could craft an Auth Request 
with the following parameters:

realm=*.goodsite.com
return_to=man.in.middle.redirect.com/legit_return_to.goodsite.com

The realm and return_to would pass verification since the final url is a 
legitimate return_to for goodsite.com. However when the OP returns a 
Positive Auth Response, man.in.middle.redirect.com could steal the 
response. Presumably man.in.middle.redirect.com would be smart enough to 
behave nicely when the OP is following the redirect, but knows how to 
steal credentials when they pass through. Perhaps goodsite.com's 
signature validation code is robust enough to detect that the return_to 
doesn't belong to it, but then again, maybe it isn't.

However, the point was that the user's OP  indicates to the user that 
they're logging into *.goodsite.com, but they're not. If the OP supports 
extensions like Simple Registration, the man in the middle would be able 
to sniff all the data, some of which might be sensitive.

Allen


Johnny Bufu wrote:
>
> This kind of playback is prevented by the return_to URL verification: 
> when goodisp.com verifies the response, it will fail because either 
> the return_to URL doesn't match with what it is expecting, or the 
> signature doesn't match (if evilsite.com modified the return_to in the 
> response).
>
> I'm still not sure I understood the full attack vector from beginning 
> to end - what is evilsite.com trying to accomplish by fooling the 
> user/OP with redirects? If you could describe a step-by-step scenario 
> it would greatly help (me at least) to understand what needs to be fixed.
>
>
> Johnny
>




More information about the security mailing list