Re: [websec] [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF
Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 26 February 2011 12:26 UTC
Return-Path: <torsten@lodderstedt.net>
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 2CA783A67D7; Sat, 26 Feb 2011 04:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.205
X-Spam-Level:
X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
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 iyaoEd1LIfVu; Sat, 26 Feb 2011 04:26:16 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 560DF3A67B6; Sat, 26 Feb 2011 04:26:15 -0800 (PST)
Received: from [79.253.40.1] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1PtJEl-0006uH-QM; Sat, 26 Feb 2011 13:27:03 +0100
Message-ID: <4D68F197.7040707@lodderstedt.net>
Date: Sat, 26 Feb 2011 13:27:03 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Manger, James H" <James.H.Manger@team.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com>
Content-Type: multipart/alternative; boundary="------------030004040703060504060508"
X-Df-Sender: torsten@lodderstedt-online.de
X-Mailman-Approved-At: Sat, 26 Feb 2011 04:33:05 -0800
Cc: "websec@ietf.org" <websec@ietf.org>, OAuth Mailing List <oauth@ietf.org>
Subject: Re: [websec] [OAUTH-WG] 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: Sat, 26 Feb 2011 12:26:21 -0000
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
- [websec] Indicating origin of OAuth credentials t… Manger, James H
- Re: [websec] [OAUTH-WG] Indicating origin of OAut… Francisco Corella
- Re: [websec] Indicating origin of OAuth credentia… Adam Barth
- Re: [websec] [OAUTH-WG] Indicating origin of OAut… Francisco Corella
- Re: [websec] [OAUTH-WG] Indicating origin of OAut… Brian Eaton
- Re: [websec] [OAUTH-WG] Indicating origin of OAut… Torsten Lodderstedt
- Re: [websec] Indicating origin of OAuth credentia… Manger, James H
- Re: [websec] Indicating origin of OAuth credentia… Adam Barth
- Re: [websec] Indicating origin of OAuth credentia… Manger, James H
- Re: [websec] Indicating origin of OAuth credentia… Adam Barth