[security] Open Redirector issue with checkid_immediate

[David Recordon]

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/10179dbf/attachment.htm>