<div>Thanks for your thoughtful response, John.</div><div>I hadn't considered that the attacker could still get a signed nonce from the RP in advance, thereby thwarting mitigation #1. It sounds like an overall good practice then for OpenID 2.0 RPs to include a signed nonce in the return_to that also includes a cookie value that must match in the browser on the return trip. Together this seems to close the hole. Then for unsolicited assertions, just add the user prompt to confirm intent.</div>
<div> </div><div>Good to know that this threat is already mitigated in OpenID Connect.</div><div><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
<br><br></div><div class="gmail_quote">On Fri, Oct 26, 2012 at 6:41 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div style>OpenID Connect inherits protection from this from OAuth2. We discussed the issues around unsolicited assertions at IIW this week. <div>The outcome of that will be a new endpoint at the RP that can trigger a Authorization request under the control of the RP. </div>
<div>This allows the RP to do frame busting etc.</div><div><br></div><div>For openID 2.0 the signature covers the realm. However an attacker could initiate a login request at the RP and capture the response for it's own account and then inject that into someone else's session.</div>
<div><br></div><div>This would not be limited to unsolicited assertions, it can with not much more effort be done to solicited assertions.</div><div>SAML with IdP initiated login is vulnerable to exactly the same attack. (Perhaps browser ID is as well though I haven't totally thought that through yet.)</div>
<div><br></div><div>The only real defence is the one in Connect/OAuth 2 where the client uses state in the request to detect browsers returning responses that don't relate to requests through that browser.</div><div>
<br>
</div><div>So unless the request includes a signed nonce based on entropy from the browser in some way, a attacker might force a user to log into a RP with a compromised account, if the RP is not frame-busting.</div><div>
<br></div><div>So I think your analysis is largely correct.</div><div><br></div><div>Other peoples thoughts. I might be wrong?</div><div><br></div><div>John B.</div><div><br></div><div><div><div><div class="h5"><div>On 2012-10-26, at 5:16 PM, Andrew Arnott <<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>> wrote:</div>
<br></div></div><blockquote type="cite"><div><div class="h5"><div>OpenID 2.0 RPs that allow unsolicited assertions (which Just Works by default for proper OpenID implementations, it seems to me) seem to be vulnerable to an attack. Can anyone confirm or deny what I'm imagining here? It seems a security advisory <em>may</em> be appropriate.</div>
<div> </div><div>The attack:</div><ol><li>Victim navigates the browser to the attacker's web site.</li><li>The web site hosts a hidden iframe that redirects to a popular RP the user is suspected to have an account with, carrying an unsolicited assertion to the attacker's identity.</li>
<li>The victim them navigates to the RP that previously received the hidden, unsolicited assertion.</li><li>The victim, unaware of the authentication, assumes that he/she is logged into their own account, and uses the RP under that assumption. They may upload files or transmit other data.</li>
<li>The attacker, who controls the account the victim is logged into, gains access to that transmitted data.</li></ol><div>Mitigations:</div><ol><li>Disable unsolicited assertions (perhaps by only accepting assertions with a return_to that includes a signed nonce from the RP).</li>
<li>Accepted unsolicited assertions, but only after frame busting code has confirmed with the user that they intended to log in as [attacker].</li></ol><div>What are your thoughts on this?</div><div><br clear="all">--<br>
Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
</div></div></div>
_______________________________________________<br>security mailing list<br><a href="mailto:security@lists.openid.net" target="_blank">security@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
</blockquote></div><br></div></div></blockquote></div><br>