Was there any conclusion?

EHL

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Manger, James H
Sent: Thursday, February 24, 2011 4:09 PM
To: OAuth Mailing List; web...@ietf.org
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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to