[security] Phishing issues with return_to url and realm

[Allen Tom]

Hi Dick,

Redirect services won't redirect a POST, or at least not the POST data. 
One potential issue with using POST is that Javascript is required to 
submit the POST automatically which prevents non-JS enabled clients from 
using the service.

I also believe that there are may be some usability issues with 
submitting a form via HTTP from a form on an HTTPS site. This is the 
case where an HTTPS OP POSTs the response to an HTTP RP. Some browsers, 
most notably IE, display a scary warning dialog box when this happens, 
however, just doing a redirect doesn't cause the same warning.

Even using POST doesn't get away from the original issue where the OP is 
telling the user that they're logging into site X, but they're not. 
Philosophically, I believe that users need to trust their OP. If 
return_to verification isn't done, then the OP isn't really sure where 
it's sending the response.

Allen


Dick Hardt wrote:
> 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
>>>
>>>
>>>
>>
>>
>