[security] Open Redirector issue with checkid_immediate

[John Bradley]

So requests with no referrer or a referrer  that is not related to the  
realm are the most problematic.

If a OP's choice is between generating an error to the user for all  
checkid_imediates or:
1 allowing them if the user is authenticated to the OP and the RP  
passes discovery.
2 allowing them if the referrer matches the retun_to
3 Showing the user a waning message in other cases such as "A site  
xyz.com has attempted to authenticate you as https:// 
ve7jtb.yahoo.com.  You are not logged in to your Yahoo account.    
Please click here if you wish to return to xyz.com"

I think picking out the likely malicious requests and displaying a  
warning to the user in those cases is likely the best short term  
option for an OP that is concerned about this.

I don't think it warrants removing checkid_imediate.

Dealing with signed requests will take some significant changes.   I  
can't say if the benefits outweigh the increased complexity.

There are two separate but related areas that need to be considered.
1.  Signing a request so that it cannot be tampered with.   This may  
be the largest affront to openID's UCI design goal if the user cannot  
modify the request,  however without some sort of smart client it is  
only attackers who might modify it today.

2. Encrypting and audience restricting the returned authenticator  
token.   NIST is clear that the "Secondary Authenticator" token must  
be protected from interception for LoA 2.   This is  interpreted for  
other protocols as encrypting the token at the OP for the RP, or  
passing the token directly from the OP to RP.

This could be added to openID if there was a will,  however some will  
legitimately ask if it is still openID once we start matching features  
with SAML?

John B.
On 9-Jun-09, at 12:53 AM, Allen Tom wrote:

> John Bradley wrote:
>>
>> 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.
>>
> The primary attack vector for phishing tends to be IM, so there  
> would be no referrer.
>>
>> 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.
> Another attack vector could be a message board, which isn't  
> necessarily a malicious message board controlled by the attacker.  
> The scenario is that the attacker posts a link on the message board  
> saying "check out my photos, click here to continue" and the victim  
> examines the link and trusts the OP's domain. The OP then redirects  
> to the attacker's site.
>
> As I said earlier, this scenario isnt' really that much different  
> than TinyURLs.
>
>>
>> I will throw in signed requests again because I have been asked why  
>> openID doesn't support that by some large potential RPs.
>>
> Requiring the RP to sign the request using a shared secret would be  
> more consistent with other auth protocols, however it would probably  
> require the RP to pre-register with each OP. This breaks a lot of  
> the autoconfiguration/autodiscovery features of OpenID.
>
> Thanks
> Allen
>