[security] Open Redirector issue with checkid_immediate

[John Bradley]

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

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