It doesn't eliminate the problem but it reduces the places a person
can be redirected to.
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.
If the user is not logged in to the OP and the referrer doesn't match
I wouldn't redirect them.
It helps if the OP uses a different domain.
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.
I suppose this could be a blog link but there are probably easier ways
to dup a user.
I suspect the major threat is from email links. In that case there
would be no referrer and the OP could detect that.
I will throw in signed requests again because I have been asked why
openID doesn't support that by some large potential RPs.
There are a set of use cases where it is important for the OP to
identify the RP.
I am OK with openID taking a pass on them but we should understand the
tradeoffs.
John B.
On 8-Jun-09, at 7:42 PM, Allen Tom wrote:
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]
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
