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

["Manger, James H" <[e-mail]>]

Torsten Lodderstedt said: "I would expect the token to carry information about its issuer. Would this be sufficient in order to detect CSRF?"

No.

A Login CSRF attack involves a legitimate token (listing the legitimate issuer) that an attacker received being given to a victim client. The client gets a legitimate token - but they got it from the wrong party so they cannot be sure it was a token meant for them.

If the client tells the resource server where they got the token from then the resource server can confirm that there wasn't an attacker between the legitimate authorization server and client.



--

James Manger







Am 25.02.2011 01:08, schrieb Manger, James H:

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