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