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

From: Adam Barth <[email-masked]>
Date: Fri, 25 Feb 2011 23:09:39 -0800

On Thu, Feb 24, 2011 at 4:08 PM, Manger, James H
<[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 14:54:38 -0700

Was there any conclusion?

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, February 24, 2011 4:09 PM
To: OAuth Mailing List; [email-masked]
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", ...}

    ...

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

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 28 Mar 2011 13:41:55 +1100

> Was there any conclusion?

My conclusion is that the Origin request header is the right place to list the OAuth authorization server to combat login CSRF attacks against apps.

The other conclusion was that you probably need fairly sophisticated & general (almost browser-like) apps for these attacks to work. OAuth is not friendly to such uses (client passwords; SHOULD pre-register redirect URI; no discovery...).

OAuth issues security tokens without indicating where they can be safely used. While that fatal flaw remains, it is pointless to specify the use of the Origin header.

The good news is that apps, services, or future specs can use the Origin header (listing the authorization server) without breaking any other parts of OAuth.

--

James Manger

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 29 Mar 2011 11:00:36 +0000

> OAuth issues security tokens without indicating where they can be safely used. While that fatal flaw remains, it is pointless to specify the use of the Origin header.

I don't think anything should be in the base as the different token profiles can stipulate the audience.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Sunday, March 27, 2011 7:42 PM
To: Eran Hammer-Lahav; OAuth Mailing List
Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 30 Mar 2011 09:57:15 +1100

> I don't think anything should be in the base as the different token profiles can stipulate the audience.

But they don't. Neither the BEARER nor MAC specs stipulate where not to send a token.

Indicating where it is safe to use a security token seems to me to be a generic requirement whenever any type of token is issued. Hence, the base spec seems to be the appropriate place to specify it.

[It is far less dangerous to use a MAC token (than a BEARER token) at the wrong site as the secret key will not be revealed. However, it is still a situation you want to avoid (at best the unexpected authentication will be ignored; often it will causes errors; and it leaks some privacy).]

The BEARER spec [draft-ietf-oauth-v2-bearer-03] does say, in its Security Considerations [3.2], "it is important for the authorization server to include the identity of the intended recipients". However this is talking about a resource server checking that a token was meant for it. It doesn't in any way prevent a client app sending the token to the wrong site (tokens can be opaque to clients so they cannot check things inside them).

--

James Manger