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
