Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

[Eran Hammer-Lahav <[e-mail]>]

Was there any conclusion?

EHL

From: [e-mail] [mailto:[e-mail]] On Behalf Of Manger, James H
Sent: Thursday, February 24, 2011 4:09 PM
To: OAuth Mailing List; [e-mail]
Subject: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

Q. Should an OAuth client app list the authorization server in the Origin header of requests to resource servers?

In OAuth (delegation) flows a server dynamically issues credentials (such as a bearer token) to a client app to use in subsequent HTTP requests to other servers. To combat login cross-site request forgery (CSRF) attacks [1] (where an attacker's server issues the attacker's credentials to a client app to use on behalf of a victim at a legitimate server) the client app needs to indicate where the credentials came from. The Origin header [2] looks like the right place to indicate this.

[For the OAuth list: The Origin HTTP request header "indicates the origin(s) that caused the user agent to issue the request" [http://tools.ietf.org/html/draft-ietf-websec-origin-00#section-6.2].]

[For the WebSec list: An OAuth credential from an authorization server is a bit like a cookie, but not restricted to the same origin.]


Example:

  Client to (malicious) authorization server: ->
    POST /token HTTP/1.1
    Host: login.example.com
    ...
  <-
    HTTP/1.1 200 OK
    ...
    { "access_token": "SlAV32hkKG", ...}

  Client to resource server: ->
    POST /uploadData HTTP/1.1
    Host: api.exampledata.com
    Authorization: BEARER SlAV32hkKG
    Origin: https://login.example.com
    ...


There can be other servers that contribute to a client app making a request. For instance, one server can redirect to another. A Origin request header can list multiple origins. The server will not be able to distinguish which origin issued OAuth credentials from which issued a redirect etc. That might not matter if a server has to trust all the values listed in the Origin header.
Q. Is it the group's expectation that servers checking the Origin header will require all the listed origins to be trusted?

[1] Robust Defenses for Cross Site Request Forgery, http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf
[2] The Web Origin Concept, http://tools.ietf.org/html/draft-ietf-websec-origin
[3] Principles of the Same Origin Policy, http://tools.ietf.org/html/draft-abarth-principles-of-origin

--
James Manger