[security] Open Redirector issue with checkid_immediate

[Allen Tom]

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 <mailto:security at openid.net>
>>> http://openid.net/mailman/listinfo/security
>>
>> _______________________________________________
>> security mailing list
>> security at openid.net <mailto: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/ad8aace9/attachment.htm>