[security] Phishing issues with return_to url and realm

[Dick Hardt]

On 8-Feb-07, at 5:36 PM, Allen Tom wrote:

> Dick Hardt wrote:
>>
>> On 8-Feb-07, at 5:03 PM, Allen Tom wrote:
>>
>>> 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
>>
>> In this example, if the realm is not contained in the domain of  
>> the return_to, the OP would report an error to the user.
> There could be several levels of redirection, so depending on how  
> the spec is phrased, the evil RP could instead do:
>
> realm=*.goodsite.com
> return_to=redirector.goodsite.com/evilrp.com/legit.goodsite.com

I don't follow how the OP checking would not be caught. Likely we  
need to be specific on what the OP is  doing.

>
> Anyway, allowing redirects in the return_to makes each intermediate  
> host a man in the middle. At the very least, the top level url in  
> the return_to should be able to verify that it's acutally an Open  
> ID 2.0 entrypoint, and it might even be desirable for the OP to be  
> able to verify the association that it has with it. For example,  
> the OP could ask the RP to tell it its association handle, or  
> perhaps to verify that it knows the secret for the given handle.

Doing some RP verification at association time has benefits, but it  
is not needed by the protocol as currently speced, so it would only  
be optional. Of course requiring verified associations could be part  
of a phishing-resistant profile.

Do you have a specific suggestion Allen?

-- Dick