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

Hi James,

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

regards,
Torsten.

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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth