Re: [websec] Indicating origin of OAuth credentials to combat login CSRF

On Thu, Feb 24, 2011 at 4:08 PM, Manger, James H
<James.H.Manger@team.telstra.com> wrote:
> Q. Should an OAuth client app list the authorization server in the Origin
> header of requests to resource servers?

They are allowed to, but are not required to, by the Origin header
specification.  Whether they should or not is a question for the OAuth
working group to decide.

Adam

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