[security] Login CSRF in OpenID Authentication

[Adam Barth]

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 <abarth at eecs.berkeley.edu> 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 <abarth at cs.stanford.edu>
> Date: Thu, Nov 15, 2007 at 5:03 PM
> To: David Recordon <drecordon at verisign.com>, Brad Fitzpatrick <brad at danga.com>
> Cc: Collin Jackson <collinj at cs.stanford.edu>, "John C. Mitchell"
> <mitchell at cs.stanford.edu>
>
>
> 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
> specs at openid.net 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
>