Apparently, I'm supposed to this mailing list from this email address. See below.
Adam On Mon, Nov 2, 2009 at 10:21 AM, Adam Barth <[email protected]> wrote: > Sorry for the epic delay in forwarding this message. David Recordon > asked me to forward this message to this list, but it fell off my > radar for two years. I haven't checked whether this is still an issue > in the most recent version of the OpenID protocol, but as far as I > know the issue hasn't been addressed. > > For more details, see Section 6.1 of > <http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf>. > > In any case, it should be easy for relying parties to fix > unilaterally. We should just tell them what to do in the spec. > > Regards, > Adam > > > --- Original Message --- > From: Adam Barth <[email protected]> > Date: Thu, Nov 15, 2007 at 5:03 PM > To: David Recordon <[email protected]>, Brad Fitzpatrick <[email protected]> > Cc: Collin Jackson <[email protected]>, "John C. Mitchell" > <[email protected]> > > > David and Brad, > > Collin, John, and I have been looking at web authentication protocols > and discovered a flaw in the OpenID Authentication protocol that is > present both in version 1.1 and in the current draft of 2.0. > > We're a bit hesitant to send the below description to the public > [email protected] email address because someone could easily use it to > infer live vulnerabilities in major web sites. We've already notified > those web sites, and we'd like to give them time to fix their > vulnerabilities. > > Overview > > The OpenID authentication protocol is vulnerable to session swapping > by a web attacker. The severity of this vulnerability depends on the > capabilities provided by relying parties. Defending against this > vulnerability requires only slight modifications to the protocol. > > Vulnerability > > If a web site (e.g., example.com) supports OpenID authentication, an > attacker who controls a malicious web page (e.g., attacker.com) can > force a visitor to attacker.com to log into example.com as the > attacker. The attack proceeds as follows: > > 1) The victim views attacker.com. > 1) The attacker visits example.com and attempts to log in via OpenID. > 2) The attacker is redirected to his OP and enters his credentials. > 3) The OP now attempts to redirect the attacker back to example.com, > but the attacker does not follow the redirect, but instead records the > URL. > 4) The attacker redirects the victim to the URL supplied by his OP. > 5) The victim is now logged into example.com as the attacker. > > Consequences > > The severity of this vulnerability depends on the capabilities > provided by the relying party. Below are a few examples: > > 1) If the relying party is a search engine that lets a user record his > or her history (such as Yahoo or Google), an attacker can silently log > the victim into his account and spy on the user's search queries. > > 2) If the relying party is an e-commerce site that lets a user > remember their credit card (such as Amazon or PayPal), an attacker can > trick the victim into enrolling the victim's credit card into the > attacker's account. After which, the attacker can transact on the > credit card. > > There are many examples of attacks that can result from this > vulnerability because sites often do not protect users from > themselves. By swapping the victim into his session, the attacker can > exploit this lack of protection against others. > > Recommendations > > The source of this vulnerability is that the OpenID authentication > does not bind to the user's browser until authentication is complete. > This enables the attacker force the victim to assume his credentials. > We recommend the specification require relying parties to bind the > browser to the authentication request at the beginning of the protocol > (probably by using a cookie). > > In Section 9.1 of Draft 12 of the OpenID Authentication 2.0 > specification, the openid.return_to request parameter has the > following note: > > "Note: The return_to URL MAY be used as a mechanism for the Relying > Party to attach context about the authentication request to the > authentication response." > > The specification should require the Relying Party to include enough > context about the authentication request so as to re-identify the > user. > > Further, we recommend adding another subsection to 15.1 that explains > Session Swapping Attacks and recommends that relying parties use the > following procedure to defend against them: > > 1) Prior to requesting authentication, the Relying Party SHOULD choose > a random nonce and store it as a cookie in the User Agent. > 2) The Relying Party SHOULD include the nonce value in the > openid.return_to parameter of the authentication request. > 3) Upon receiving a positive assertion, the Relying Party SHOULD > verify that the nonce value from the openid.return_to parameter > matches the value stored in the cookie. > > Adam > _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
