[security] Phishing issues with return_to url and realm

[Dick Hardt]

Hi Allen

I just realized that although you can use either a POST or a GET with  
OpenID 2.0, our libraries use a POST. Would I be correct that the  
redirect services would NOT redirect a POST? If so, then an OP can  
protect against the attack by using POST instead of GET.

-- Dick

On 7-Feb-07, at 10:20 PM, Allen Tom wrote:

> 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
>>
>>
>>
>
>