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

"Manger, James H" <James.H.Manger@team.telstra.com> Fri, 25 February 2011 00:07 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: websec@core3.amsl.com
Delivered-To: websec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7D53A688A; Thu, 24 Feb 2011 16:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.088
X-Spam-Level:
X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY1GMoJ0BdAe; Thu, 24 Feb 2011 16:07:48 -0800 (PST)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 367033A635F; Thu, 24 Feb 2011 16:07:45 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.62,221,1296997200"; d="scan'208,217"; a="29521350"
Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 25 Feb 2011 11:08:35 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6267"; a="20255544"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcdni.tcif.telstra.com.au with ESMTP; 25 Feb 2011 11:08:35 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 25 Feb 2011 11:08:34 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: OAuth Mailing List <oauth@ietf.org>, "websec@ietf.org" <websec@ietf.org>
Date: Fri, 25 Feb 2011 11:08:33 +1100
Thread-Topic: Indicating origin of OAuth credentials to combat login CSRF
Thread-Index: AcvUgCPYCfnEh2l8Tj+BafbhN2rcIQ==
Message-ID: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127DCD2142WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: [websec] Indicating origin of OAuth credentials to combat login CSRF
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Feb 2011 00:07:53 -0000

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