[security] Phishing issues with return_to url and realm

[Allen Tom]

Hi Johnny,

Having the OP follow all the redirects returned by the return_to all the 
way to the end, and presenting the final url to the user might seem to 
be an improvement, however, the evil RP could just be one of many 
intermediate servers, which would enable all sorts of interesting man in 
the middle type attacks.

so for instance:

return_to=go.com/redirect?1,2,http://evilsite.com/redirect?....good.isp.com

If the OP just followed redirects to the end of return_to url, and then 
matched it up with the realm, the evil RP could claim to be absolutely 
anything that it wants to be, since the evil RP could just be the 
redirect server, and the claimed site would just be at the end.

evilsite.com would be able grab a positive Auth Response and play it to 
good.isp.com in a Stateless type request. EvilSite.com could even behave 
nicely when the OP is probing it (perhaps by recognizing the OP's IP 
address or User Agent).

At any rate, when serving an Auth Request, the OP only knows the 
return_to url,  so there should be a way in the protocol for the OP to 
somehow verify the return_to url. Instead of performing the verification 
on every request, the OP and the RP could register themselves and do 
whatever verification is required during the association process.

One possibility would be for the RP to pass its return_to url when 
making the Association Request, and the OP can probe it before returning 
the assoc_handle and secret. It might be sufficient for the OP to just 
bind that assoc_handle to the return_to url, so one possible 
implementation would be for the OP to encrypt details about the 
association into the assoc_handle, so that the given assoc_handle can 
only be used for that return_to. However, it might be necessary for the 
OP to verify that the RP owning the return_to URL actually initiated the 
Association  request, so perhaps an additional round trip would be 
needed after the association is initiated.

Allen



Johnny Bufu wrote:
>
> Another simpler (though maybe not as solid) solution would be for the 
> OP to perform a fetch on the return_to URL and present the final URL - 
> after following the redirects - in the message to the user. So the 
> user will actually see that he's about to go to http://www.jyte.com, for:
>
>     return_to=http://www.aol.com/ams/clickThruRedirect.adp?1,2,http://www.jyte.com 
>
>
> If the rogue RP further tries to hide itself by setting 
> realm=*.aol.com, the realm verification performed by the OP will fail 
> (again, using the return_to URL after following redirects).
>
>
> Johnny
>
>
>