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
[email protected] <mailto:[email protected]>
http://openid.net/mailman/listinfo/security
_______________________________________________
security mailing list
[email protected] <mailto:[email protected]>
http://openid.net/mailman/listinfo/security
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
