Yes that is the strategy we are going to take with Connect. John B.
On 2012-10-26, at 7:31 PM, Andrew Arnott <[email protected]> wrote: > Thanks for your thoughtful response, John. > 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. > > Good to know that this threat is already mitigated in OpenID Connect. > > -- > Andrew Arnott > "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 > > > On Fri, Oct 26, 2012 at 6:41 PM, John Bradley <[email protected]> wrote: > OpenID Connect inherits protection from this from OAuth2. We discussed the > issues around unsolicited assertions at IIW this week. > The outcome of that will be a new endpoint at the RP that can trigger a > Authorization request under the control of the RP. > This allows the RP to do frame busting etc. > > 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. > > This would not be limited to unsolicited assertions, it can with not much > more effort be done to solicited assertions. > 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.) > > 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. > > 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. > > So I think your analysis is largely correct. > > Other peoples thoughts. I might be wrong? > > John B. > > On 2012-10-26, at 5:16 PM, Andrew Arnott <[email protected]> wrote: > >> 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 may be appropriate. >> >> The attack: >> Victim navigates the browser to the attacker's web site. >> 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. >> The victim them navigates to the RP that previously received the hidden, >> unsolicited assertion. >> 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. >> The attacker, who controls the account the victim is logged into, gains >> access to that transmitted data. >> Mitigations: >> Disable unsolicited assertions (perhaps by only accepting assertions with a >> return_to that includes a signed nonce from the RP). >> Accepted unsolicited assertions, but only after frame busting code has >> confirmed with the user that they intended to log in as [attacker]. >> What are your thoughts on this? >> >> -- >> Andrew Arnott >> "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 >> _______________________________________________ >> security mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-security > >
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
