[security] Open Redirector issue with checkid_immediate

[John Bradley]

It doesn't eliminate the problem but it reduces the places a person  
can be redirected to.

There is also nothing to stop the OP from checking the referrer,  if  
the referring site is different from the return_to that is suspicious.

If the user is not logged in to the OP and the referrer doesn't match  
I wouldn't redirect them.

It helps if the OP uses a different domain.

If his is used on a web site it seems like a lot of trouble to go to.   
They are all ready on a bad site.
I suppose this could be a blog link but there are probably easier ways  
to dup a user.

I suspect the major threat is from email links.  In that case there  
would be no referrer and the OP could detect that.

I will throw in signed requests again because I have been asked why  
openID doesn't support that by some large potential RPs.

There are a set of use cases where it is important for the OP to  
identify the RP.

I am OK with openID taking a pass on them but we should understand the  
tradeoffs.

John B.

On 8-Jun-09, at 7:42 PM, Allen Tom wrote:

> John & David - initially, I thought that RP discovery would help  
> address this issue, but it doesn't. The attacker would just host a  
> valid discovery document to trick the OP into redirecting to the  
> attacker's site.
>
> This openid redirector issue is one of the reasons why Yahoo hosts  
> our OpenID endpoints on an alternate domain, instead of *.yahoo.com.
>
> Allen
>
> David Recordon wrote:
>>
>> Yes, I think RP discovery definitely allows OPs a way to help limit  
>> these redirects to actual RPs if they are concerned about this  
>> case.  I certainly wouldn't put signed requests into the 2.1  
>> bucket, but I do think that there are definite tradeoffs around  
>> OpenID's design and flexibility compared to concerns such as this  
>> one.  I do however believe this to be fairly well known already by  
>> OpenID Providers already, at least the large ones.
>>
>> --David
>>
>> On Jun 8, 2009, at 2:39 PM, John Bradley wrote:
>>
>>> Allen,
>>>
>>> I will bite.
>>>
>>> A checkid_setup will do the same thing at most OP's if the user  
>>> has elected to remember the RP.
>>>
>>> A feature/flaw of openID is that requests are not signed in any way.
>>>
>>> If an OP is to ever trust any request as coming from the RP  
>>> indicated by the realm/return_to then this will need to be  
>>> addressed.
>>>
>>> Given that checkid_immediate is generally no worse than  
>>> checkid_setup,  is forcing a user dialog for checkid_setup and  
>>> eliminating checkid_immediate too big a loss of functionality  
>>> compared to the risk presented to users.
>>>
>>> Perhaps a intermediate measure would be for the OP to error if RP  
>>> discovery fails for a checkid_imediate.
>>>
>>> That at least limits the possible redirect targets to OP's  
>>> return_to URI.
>>>
>>> I suspect that RP discovery is the short term answer and the long  
>>> term is signed requests of some sort in openID 2.1.
>>>
>>> John  B.
>>> On 8-Jun-09, at 5:11 PM, Allen Tom wrote:
>>>
>>>> Hi All,
>>>>
>>>> I believe that everything in the Security Best Practices document  
>>>> has already been discussed publicly, except for the  
>>>> checkid_immediate "open redirector" issue listed in the OP Best  
>>>> Practices section.
>>>>
>>>> In a nutshell, checkid_immediate can be used as an open  
>>>> redirector, forcing the OP to redirect the browser with the  
>>>> response to the return_to URL. This interface can potentially be  
>>>> misused to make checkid_immediate behave similarly TinyURLs, in  
>>>> which an attacker could obfuscate a link by hiding it behind an  
>>>> OP's checkid_immediate interface.
>>>>
>>>> If anyone would like to discuss using checkid_immdiate as an Open  
>>>> Redirector, this we should do it here.
>>>>
>>>> Thanks
>>>> Allen
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> security mailing list
>>>> security at openid.net
>>>> http://openid.net/mailman/listinfo/security
>>>
>>> _______________________________________________
>>> security mailing list
>>> security at openid.net
>>> http://openid.net/mailman/listinfo/security
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20090608/f5ec3d1c/attachment.htm>