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