<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
This openid redirector issue is one of the reasons why Yahoo hosts our
OpenID endpoints on an alternate domain, instead of *.yahoo.com. <br>
<br>
Allen<br>
<br>
David Recordon wrote:
<blockquote cite="mid:A5876299-788A-48E9-9B5C-51E95185E59A@sixapart.com"
type="cite">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.
<div><br>
</div>
<div>--David</div>
<div><br>
<div>
<div>On Jun 8, 2009, at 2:39 PM, John Bradley wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="">Allen,
<div><br>
</div>
<div>I will bite.</div>
<div><br>
</div>
<div>A checkid_setup will do the same thing at most OP's if the
user has elected to remember the RP.</div>
<div><br>
</div>
<div>A feature/flaw of openID is that requests are not signed in
any way.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Perhaps a intermediate measure would be for the OP to error if
RP discovery fails for a checkid_imediate. </div>
<div><br>
</div>
<div>That at least limits the possible redirect targets to OP's
return_to URI.</div>
<div><br>
</div>
<div>I suspect that RP discovery is the short term answer and the
long term is signed requests of some sort in openID 2.1.</div>
<div><br>
</div>
<div>John B.<br>
<div>
<div>On 8-Jun-09, at 5:11 PM, Allen Tom wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>Hi All,<br>
<br>
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.<br>
<br>
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.<br>
<br>
If anyone would like to discuss using checkid_immdiate as an Open
Redirector, this we should do it here.<br>
<br>
Thanks<br>
Allen<br>
<br>
<br>
<br>
_______________________________________________<br>
security mailing list<br>
<a moz-do-not-send="true" href="mailto:security@openid.net">security@openid.net</a><br>
<a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/security">http://openid.net/mailman/listinfo/security</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
security mailing list<br>
<a moz-do-not-send="true" href="mailto:security@openid.net">security@openid.net</a><br>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/security">http://openid.net/mailman/listinfo/security</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>