From ietf@adambarth.com Fri Feb 4 17:56:26 2011 Return-Path: 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 2D9B93A68FD for ; Fri, 4 Feb 2011 17:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 G085KCb7wVWz for ; Fri, 4 Feb 2011 17:56:25 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 5A5C53A69B0 for ; Fri, 4 Feb 2011 17:56:25 -0800 (PST) Received: by vws7 with SMTP id 7so2019523vws.31 for ; Fri, 04 Feb 2011 17:59:51 -0800 (PST) Received: by 10.220.91.212 with SMTP id o20mr3065580vcm.140.1296871191244; Fri, 04 Feb 2011 17:59:51 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id c8sm612277vcc.9.2011.02.04.17.59.50 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 17:59:50 -0800 (PST) Received: by vws7 with SMTP id 7so2019513vws.31 for ; Fri, 04 Feb 2011 17:59:49 -0800 (PST) Received: by 10.220.182.71 with SMTP id cb7mr3504062vcb.73.1296871189412; Fri, 04 Feb 2011 17:59:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.165.212 with HTTP; Fri, 4 Feb 2011 17:59:19 -0800 (PST) From: Adam Barth Date: Fri, 4 Feb 2011 17:59:19 -0800 Message-ID: To: websec Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] draft-ietf-websec-mime-sniff-02 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 01:56:26 -0000 I've uploaded a new draft of the media type sniffing document: http://www.ietf.org/id/draft-ietf-websec-mime-sniff-02.txt This version includes support for H.264 and contains a hook for sniffing for video specifically. (Although now that I look at it, I realize that I've goofed it up and forgotten to include Ogg---will fix in next version.) The H.264 signature is somewhat more complex than the other signatures, but it appears to be necessary due to the structure of H.264 video files. Please let me know that that signature will cause any trouble for you. Thanks, Adam From ietf@adambarth.com Fri Feb 4 17:57:26 2011 Return-Path: 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 E5FF73A659C for ; Fri, 4 Feb 2011 17:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=-1.215, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 dPG74eFhoh4X for ; Fri, 4 Feb 2011 17:57:26 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 17A003A6875 for ; Fri, 4 Feb 2011 17:57:26 -0800 (PST) Received: by vxi40 with SMTP id 40so999994vxi.31 for ; Fri, 04 Feb 2011 18:00:52 -0800 (PST) Received: by 10.220.198.134 with SMTP id eo6mr3180571vcb.277.1296871252291; Fri, 04 Feb 2011 18:00:52 -0800 (PST) Received: from mail-vx0-f172.google.com ([209.85.220.172]) by mx.google.com with ESMTPS id i1sm1057626vby.1.2011.02.04.18.00.50 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 18:00:51 -0800 (PST) Received: by vxi40 with SMTP id 40so999980vxi.31 for ; Fri, 04 Feb 2011 18:00:50 -0800 (PST) Received: by 10.220.182.9 with SMTP id ca9mr3516335vcb.3.1296871250284; Fri, 04 Feb 2011 18:00:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.165.212 with HTTP; Fri, 4 Feb 2011 18:00:20 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Fri, 4 Feb 2011 18:00:20 -0800 Message-ID: To: websec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [websec] draft-ietf-websec-mime-sniff-02 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 01:57:27 -0000 I should also say that I've added a section for fonts, but I didn't know what to write there. If you know something about sniffing for fonts, please let me know. Thanks, Adam On Fri, Feb 4, 2011 at 5:59 PM, Adam Barth wrote: > I've uploaded a new draft of the media type sniffing document: > > http://www.ietf.org/id/draft-ietf-websec-mime-sniff-02.txt > > This version includes support for H.264 and contains a hook for > sniffing for video specifically. =A0(Although now that I look at it, I > realize that I've goofed it up and forgotten to include Ogg---will fix > in next version.) > > The H.264 signature is somewhat more complex than the other > signatures, but it appears to be necessary due to the structure of > H.264 video files. =A0Please let me know that that signature will cause > any trouble for you. > > Thanks, > Adam > From Internet-Drafts@ietf.org Fri Feb 4 18:00:04 2011 Return-Path: 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 9B1123A6A3D; Fri, 4 Feb 2011 18:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 yyeE64qpIC6z; Fri, 4 Feb 2011 18:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9367E3A659C; Fri, 4 Feb 2011 18:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110205020001.14052.17588.idtracker@localhost> Date: Fri, 04 Feb 2011 18:00:01 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action:draft-ietf-websec-mime-sniff-02.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 02:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. Title : Media Type Sniffing Author(s) : A. Barth, I. Hickson Filename : draft-ietf-websec-mime-sniff-02.txt Pages : 23 Date : 2011-02-04 Many web servers supply incorrect Content-Type header fields with their HTTP responses. In order to be compatible with these servers, user agents consider the content of HTTP responses as well as the Content-Type header fields when determining the effective media type of the response. This document describes an algorithm for determining the effective media type of HTTP responses that balances security and compatibility considerations. Please send feedback on this draft to websec@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-mime-sniff-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-websec-mime-sniff-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-04175216.I-D@ietf.org> --NextPart-- From yuhongbao_386@hotmail.com Sat Feb 5 00:21:10 2011 Return-Path: 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 F1AF73A6888 for ; Sat, 5 Feb 2011 00:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] 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 uQEYKsVZVQVR for ; Sat, 5 Feb 2011 00:21:09 -0800 (PST) Received: from snt0-omc1-s17.snt0.hotmail.com (snt0-omc1-s17.snt0.hotmail.com [65.55.90.28]) by core3.amsl.com (Postfix) with ESMTP id 1EC453A68DF for ; Sat, 5 Feb 2011 00:21:09 -0800 (PST) Received: from SNT125-W45 ([65.55.90.7]) by snt0-omc1-s17.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 5 Feb 2011 00:24:35 -0800 Message-ID: X-Originating-IP: [71.112.243.235] From: Yuhong Bao To: Date: Sat, 5 Feb 2011 00:24:35 -0800 Importance: Normal Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 05 Feb 2011 08:24:35.0978 (UTC) FILETIME=[1F8D9EA0:01CBC50E] X-Mailman-Approved-At: Sat, 05 Feb 2011 13:24:01 -0800 Subject: [websec] =?windows-1256?q?On_draft-ietf-websec-mime-sniff-01=2E?= =?windows-1256?b?Li7+?= X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 08:21:10 -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 iss= ues credentials (such as a bearer token) to a client app to use in subseque= nt HTTP requests to other servers. To combat login cross-site request forge= ry (CSRF) attacks [1] (where an attacker’s server issues the attacker’s credentials to a client app to use on b= ehalf 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 requ= est” [http://tools.ietf.org/html/draft-ietf-websec-origin-00#section-= 6.2].]

 

[For the WebSec list: An OAuth credential from an au= thorization server is a bit like a cookie, but not restricted to the same o= rigin.]

 

 

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<= o:p>

    Origin: https://login.example.com=

    …

 

 

There can be other servers that contribute to a clie= nt 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 a= ble 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 truste= d?

 

[1] Robust Defenses for Cross Site Request Forgery, = http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf<= /o:p>

[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

 

--_000_255B9BB34FB7D647A506DC292726F6E1127DCD2142WSMSG3153Vsrv_-- From fcorella@pomcor.com Fri Feb 25 17:53:51 2011 Return-Path: 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 1FC973A6A48 for ; Fri, 25 Feb 2011 17:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Gv1fjUYuIQmU for ; Fri, 25 Feb 2011 17:53:49 -0800 (PST) Received: from nm23-vm0.bullet.mail.ac4.yahoo.com (nm23-vm0.bullet.mail.ac4.yahoo.com [98.139.53.220]) by core3.amsl.com (Postfix) with SMTP id 66E003A6A0B for ; Fri, 25 Feb 2011 17:53:49 -0800 (PST) Received: from [98.139.52.194] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 01:54:39 -0000 Received: from [98.139.52.171] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 01:54:39 -0000 Received: from [127.0.0.1] by omp1054.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 01:54:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 916223.83907.bm@omp1054.mail.ac4.yahoo.com Received: (qmail 19488 invoked by uid 60001); 26 Feb 2011 01:54:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298685279; bh=Y6DYoZRHXkUi8maM5KEp5EmrARL7CQJR8g2mVPGmS4E=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Xw52HcGYD5fvshaZyUS4rKGpYItcFTtY8ogIsyCSX1wfNeKRwmQRhZkTWf3w4zbgDcc1KLoh5tfVaKlZDI0XNAdNQmGofeufXpKmXZkA53NRaZuDL2y2geaMdke2W4z1PICbJDakEHooPXg7WzWOgT0STSGfEfowJ2ElNh7c15g= Message-ID: <805657.18502.qm@web55805.mail.re3.yahoo.com> X-YMail-OSG: a_bnh0oVM1mQ27523OXTyJQJXFC0R4dgh5XBMQ2hpDrsTsW JV9fKrNlW2DAar.WfxyFSG.86.xFiFfPm2rw0p0E1baSIMhl_QeNGq1RTKXk 3BNgk59EU7.v.Od96t0odNNbJXS6qHFBi7Oy6rZuSkBwlG9SJcr6j1IzK59i pH9_lBFckEx5nQq4aFgwD2m3SaCm9kH07jmi6vjHV1k7lOFeUd474F5g1.wZ .SNetsAknrrRO5uRNHrftT38K8U.kXjNhcgdxVA1MLcuCtYJtq.pjv.HK4xD sLLV5X9B5uoqjHFbb76FCujk_WDrKc7NVgiaX0_zjKtRmpZOTo9Qe_eVUj3w kzBRizS0- Received: from [67.91.91.101] by web55805.mail.re3.yahoo.com via HTTP; Fri, 25 Feb 2011 17:54:39 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Fri, 25 Feb 2011 17:54:39 -0800 (PST) From: Francisco Corella To: Brian Eaton In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1828664380-1298685279=:18502" Cc: "websec@ietf.org" , OAuth Mailing List , "Karen P. Lewison" 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 Reply-To: fcorella@pomcor.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 01:53:51 -0000 --0-1828664380-1298685279=:18502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There is nothing wrong with telling people that they should prevent CSRF at= tacks :-) But there is no explicit state parameter in OAuth 1.0a.=C2=A0 Do you think = that implementors of 1.0a, just by reading section 11.14, are aware of the = danger of Login CSRF and can figure out how to prevent it, using a pre-sess= ion cookie and implementing a state parameter that is not even mentioned in= the specification? Francisco --- On Sat, 2/26/11, Brian Eaton wrote: From: Brian Eaton Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat lo= gin CSRF To: fcorella@pomcor.com Cc: "OAuth Mailing List" , "websec@ietf.org" , "James HManger" , "Karen P. Lewison" = Date: Saturday, February 26, 2011, 12:36 AM I don't think the advice from the OAuth 1.0a spec is wrong: http://oauth.net/core/1.0a/#anchor38 "Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. Service Providers SHOULD strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the User at the Consumer site intended to complete the OAuth negotiation with the Service Provider." This is the purpose of the "state" parameter during the approval flows. Cheers, Brian On Fri, Feb 25, 2011 at 3:42 PM, Francisco Corella wr= ote: > > Hi James, > > You raise an interesting point.=C2=A0 I hadn't thought about the > threat of 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=E2=80=9A=C3=84=C3=B4s server issues the attacker=E2=80=9A= =C3=84=C3=B4s credentials to a > > client app ... > > But how will the client app get the "credentials" (bearer token) > from the wrong authorization server? > > Even though the particular attack you describe may not work, > OAuth is wide open to Login CSRF in a different way.=C2=A0 An > attacker can legitimately obtain an authorization code, and > then cause the victim's browser to submit it to the client > application, thus logging the victim in to the client > application as the attacker (in a social login scenario such > as "log in with Facebook").=C2=A0 I bet all applications that use > OAuth to delegate authentication (to Facebook, Twitter, > Google, LinkedIn, Yahoo, etc.) are vulnerable to this now. > > One solution I would propose is to have the client set a > pre-session cookie in the user's browser before the first > redirection and include the value of the cookie in the local > state parameter that it sends to the authorization server. > The authorization server later returns the local state > together with the authorization code, and the browser adds > the cookie, so the client can prevent the attack by checking > that the value of the cookie agrees with the value it > included in the local state. > > Francisco > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0-1828664380-1298685279=:18502 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There is nothing wrong with telling people th= at they should prevent CSRF attacks :-)

But there is no explicit sta= te parameter in OAuth 1.0a.  Do you think that implementors of 1.0a, j= ust by reading section 11.14, are aware of the danger of Login CSRF and can= figure out how to prevent it, using a pre-session cookie and implementing = a state parameter that is not even mentioned in the specification?

F= rancisco

--- On Sat, 2/26/11, Brian Eaton <beaton@google.co= m> wrote:

From: Brian Eaton <= beaton@google.com>
Subject: Re: [OAUTH-WG] Indicating origin of OAuth= credentials to combat login CSRF
To: fcorella@pomcor.com
Cc: "OAuth = Mailing List" <oauth@ietf.org>, "websec@ietf.org" <websec@ietf.org= >, "James HManger" <James.H.Manger@team.telstra.com>, "Karen P. Lewison= " <kplewison@pomcor.com>
Date: Saturday, February 26, 2011, 12:36 = AM

I don't think the advice from the OAuth = 1.0a spec is wrong:

http://oauth.net/core/1.0a/#anchor38

"Cross-S= ite Request Forgery (CSRF) is a web-based attack whereby HTTP
requests a= re transmitted from a user that the website trusts or has
authenticated.= CSRF attacks on OAuth approvals can allow an attacker
to obtain authori= zation to OAuth Protected Resources without the
consent of the User. Ser= vice Providers SHOULD strongly consider best
practices in CSRF preventio= n at all OAuth endpoints.

CSRF attacks on OAuth callback URLs hosted= by Consumers are also
possible. Consumers should prevent CSRF attacks o= n OAuth callback URLs
by verifying that the User at the Consumer site intended to complete
the OAuth negotiation with the Service Provider."<= br>
This is the purpose of the "state" parameter during the approval flo= ws.

Cheers,
Brian

On Fri, Feb 25, 2011 at 3:42 PM, Francis= co Corella <fcorella@pomcor.com> wrote:
>
&= gt; Hi James,
>
> You raise an interesting point.  I hadn'= t thought about the
> threat of Login CSRF.
>
> > Q. S= hould an OAuth client app list the authorization server
> > in the= Origin header of requests to resource servers?
> >
> > I= n OAuth (delegation) flows a server dynamically issues
> > credent= ials (such as a bearer token) to a client app to use
> > in subseq= uent HTTP requests to other servers. To combat
> > login cross-sit= e request forgery (CSRF) attacks [1] (where
> > an attacker=E2=80=9A=C3=84=C3=B4s server issues the attacker=E2=80=9A=C3=84= =C3=B4s credentials to a
> > client app ...
>
> But ho= w will the client app get the "credentials" (bearer token)
> from the= wrong authorization server?
>
> Even though the particular att= ack you describe may not work,
> OAuth is wide open to Login CSRF in = a different way.  An
> attacker can legitimately obtain an autho= rization code, and
> then cause the victim's browser to submit it to = the client
> application, thus logging the victim in to the client> application as the attacker (in a social login scenario such
> = as "log in with Facebook").  I bet all applications that use
> O= Auth to delegate authentication (to Facebook, Twitter,
> Google, Link= edIn, Yahoo, etc.) are vulnerable to this now.
>
> One solution= I would propose is to have the client set a
> pre-session cookie in = the user's browser before the first
> redirection and include the value of the cookie i= n the local
> state parameter that it sends to the authorization serv= er.
> The authorization server later returns the local state
> = together with the authorization code, and the browser adds
> the cook= ie, so the client can prevent the attack by checking
> that the value= of the cookie agrees with the value it
> included in the local state= .
>
> Francisco
>
>
> _______________________= ________________________
> OAuth mailing list
> OAuth@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/oauth
>
--0-1828664380-1298685279=:18502-- From ietf@adambarth.com Fri Feb 25 23:09:22 2011 Return-Path: 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 694F53A691B; Fri, 25 Feb 2011 23:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 6JxNyhCSLUAO; Fri, 25 Feb 2011 23:09:16 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AABEB3A68A0; Fri, 25 Feb 2011 23:09:16 -0800 (PST) Received: by iwl42 with SMTP id 42so1902795iwl.31 for ; Fri, 25 Feb 2011 23:10:11 -0800 (PST) Received: by 10.231.161.15 with SMTP id p15mr3530063ibx.104.1298704210675; Fri, 25 Feb 2011 23:10:10 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id 8sm1627920iba.22.2011.02.25.23.10.09 (version=SSLv3 cipher=OTHER); Fri, 25 Feb 2011 23:10:09 -0800 (PST) Received: by iwl42 with SMTP id 42so1902774iwl.31 for ; Fri, 25 Feb 2011 23:10:09 -0800 (PST) Received: by 10.231.160.80 with SMTP id m16mr3552715ibx.106.1298704209087; Fri, 25 Feb 2011 23:10:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.40.7 with HTTP; Fri, 25 Feb 2011 23:09:39 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> From: Adam Barth Date: Fri, 25 Feb 2011 23:09:39 -0800 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" , OAuth Mailing List Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 07:09:23 -0000 On Thu, Feb 24, 2011 at 4:08 PM, Manger, James H 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 oth= er > servers. To combat login cross-site request forgery (CSRF) attacks [1] > (where an attacker=92s server issues the attacker=92s credentials to a cl= ient > 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 =93indicates the orig= in(s) > that caused the user agent to issue the request=94 > [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: > > > > =A0 Client to (malicious) authorization server: -> > > =A0 =A0=A0POST /token HTTP/1.1 > > =A0 =A0=A0Host: login.example.com > > =A0 =A0=A0=85 > > =A0 <- > > =A0 =A0=A0HTTP/1.1 200 OK > > =A0 =A0=A0=85 > > =A0 =A0=A0{ "access_token": "SlAV32hkKG", =85} > > > > =A0 Client to resource server: -> > > =A0 =A0=A0POST /uploadData HTTP/1.1 > > =A0 =A0=A0Host: api.exampledata.com > > =A0 =A0=A0Authorization: BEARER SlAV32hkKG > > =A0 =A0=A0Origin: https://login.example.com > > =A0=A0=A0 =85 > > > > > > There can be other servers that contribute to a client app making a reque= st. > For instance, one server can redirect to another. A Origin request header > can list multiple origins. The server will not be able to distinguish whi= ch > origin issued OAuth credentials from which issued a redirect etc. That mi= ght > not matter if a server has to trust all the values listed in the Origin > header. > > Q. Is it the group=92s expectation that servers checking the Origin heade= r > 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 > > From fcorella@pomcor.com Fri Feb 25 15:41:11 2011 Return-Path: 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 235D43A6A7C for ; Fri, 25 Feb 2011 15:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Lv0aAeqmy5LZ for ; Fri, 25 Feb 2011 15:41:10 -0800 (PST) Received: from nm24.bullet.mail.ac4.yahoo.com (nm24.bullet.mail.ac4.yahoo.com [98.139.52.221]) by core3.amsl.com (Postfix) with SMTP id 0A60A3A6A78 for ; Fri, 25 Feb 2011 15:41:09 -0800 (PST) Received: from [98.139.52.194] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 25 Feb 2011 23:42:00 -0000 Received: from [98.139.52.140] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 25 Feb 2011 23:42:00 -0000 Received: from [127.0.0.1] by omp1023.mail.ac4.yahoo.com with NNFMP; 25 Feb 2011 23:42:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 793241.38881.bm@omp1023.mail.ac4.yahoo.com Received: (qmail 25996 invoked by uid 60001); 25 Feb 2011 23:42:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298677320; bh=HSGzYKvQPrpXOIEWR1Uw6+e4x3sCVRqsJUXMdE+Q0l4=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ygJYzq8Wc818Fy2UHLEQK76ZbDOtY8go8ALTfNVBVVJSTp1LS82a60e8vvxKhTbx4QCGY+1JjOGKBxHorO7ls/E0WeF6LKhbRGQfNHFVvNv/IbI76jiryFFA4u7Ru+/FB78/BBWgjQ4utVo5aQCMILgDxdPuGxaaBAVJH3Bv2uw= Message-ID: <593793.24331.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: UvntHMIVM1nHs6wx6O5UHJAT9M2R3MUj8Jljl0PyS7W0SvF U6WxZeQnCho5yduN73.gc08bxMzCr06x5D8AloKd1NfMp1oMbYkvDFWsFI8i 5sw5.N9YlTl4BmAYpZHyWAXAdsCGf27kBIMdMC5eyVglDIdMmfk8J0Ul2LS_ mj5oSGpffbkITpk5bQ.r62rLhLnvV3ifytfzfBQseKLViYBMgive6FNymn7. kxZ6mPGan8TwZyXPw_QWBUsaOt5BzsylisF6tJtnmJJpss3PZxqHX6OcevGv _dZSujNuvJeL52bDxbvcAZ_4nvYLVPQE3DleSo_pcC73K_S8XNM4f0tyCXRb OWYkK4WnuEIqD9lvYgGLuBmKmhIfKOSJP9v0WNYkR5WC2jqq8mOtNVs9m4zC st6U- Received: from [67.91.91.101] by web55801.mail.re3.yahoo.com via HTTP; Fri, 25 Feb 2011 15:42:00 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Fri, 25 Feb 2011 15:42:00 -0800 (PST) From: Francisco Corella To: OAuth Mailing List , "websec@ietf.org" , James HManger In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1990049981-1298677320=:24331" X-Mailman-Approved-At: Sat, 26 Feb 2011 02:46:33 -0800 Cc: "Karen P. Lewison" 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 Reply-To: fcorella@pomcor.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 23:41:11 -0000 --0-1990049981-1298677320=:24331 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi James, You raise an interesting point.=C2=A0 I hadn't thought about the threat of Login CSRF. > Q. Should an OAuth client app list the authorization server > in the Origin header of requests to resource servers? >=20 > 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=E2=80=9A=C3=84=C3=B4s server issues the attacker=E2=80=9A=C3= =84=C3=B4s credentials to a > client app ... But how will the client app get the "credentials" (bearer token) from the wrong authorization server? Even though the particular attack you describe may not work, OAuth is wide open to Login CSRF in a different way.=C2=A0 An attacker can legitimately obtain an authorization code, and then cause the victim's browser to submit it to the client application, thus logging the victim in to the client application as the attacker (in a social login scenario such as "log in with Facebook").=C2=A0 I bet all applications that use OAuth to delegate authentication (to Facebook, Twitter, Google, LinkedIn, Yahoo, etc.) are vulnerable to this now. One solution I would propose is to have the client set a pre-session cookie in the user's browser before the first redirection and include the value of the cookie in the local state parameter that it sends to the authorization server. The authorization server later returns the local state together with the authorization code, and the browser adds the cookie, so the client can prevent the attack by checking that the value of the cookie agrees with the value it included in the local state. Francisco --0-1990049981-1298677320=:24331 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi James,

You raise an interesting poi= nt.  I hadn't thought about the
threat of Login CSRF.

> Q= . Should an OAuth client app list the authorization server
> in the O= rigin header of requests to resource servers?
>
> In OAuth (de= legation) 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) a= ttacks [1] (where
> an attacker=E2=80=9A=C3=84=C3=B4s server issues t= he attacker=E2=80=9A=C3=84=C3=B4s credentials to a
> client app ...
But how will the client app get the "credentials" (bearer token)
f= rom the wrong authorization server?

Even though the particular attac= k you describe may not work,
OAuth is wide open to Login CSRF in a diffe= rent way.  An
attacker can legitimately obtain an authorization code, and
then cause the victi= m's browser to submit it to the client
application, thus logging the vic= tim in to the client
application as the attacker (in a social login scen= ario such
as "log in with Facebook").  I bet all applications that = use
OAuth to delegate authentication (to Facebook, Twitter,
Google, L= inkedIn, Yahoo, etc.) are vulnerable to this now.

One solution I wou= ld propose is to have the client set a
pre-session cookie in the user's = browser before the first
redirection and include the value of the cookie= in the local
state parameter that it sends to the authorization server.=
The authorization server later returns the local state
together with= the authorization code, and the browser adds
the cookie, so the client = can prevent the attack by checking
that the value of the cookie agrees w= ith the value it
included in the local state.

Francisco

--0-1990049981-1298677320=:24331-- From beaton@google.com Fri Feb 25 16:35:26 2011 Return-Path: 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 F0EEC3A6A97 for ; Fri, 25 Feb 2011 16:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 HxP6N4AobnbZ for ; Fri, 25 Feb 2011 16:35:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1A7EE3A6A92 for ; Fri, 25 Feb 2011 16:35:20 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p1Q0aDaw027980 for ; Fri, 25 Feb 2011 16:36:13 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298680573; bh=9Mx3R7YzqV+mP/Mf46ko+Oq171w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=QbW+PNEUGLW3MJ7JO6/62kHo9bw0YRI6GB+E20sfOxTWHNPjr1u231Vo6Qinnjr5P GvoHogcOx8oDgHsVHRdzw== Received: from pxi2 (pxi2.prod.google.com [10.243.27.2]) by kpbe16.cbf.corp.google.com with ESMTP id p1Q0aAYU012156 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 25 Feb 2011 16:36:11 -0800 Received: by pxi2 with SMTP id 2so457844pxi.24 for ; Fri, 25 Feb 2011 16:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qtf/+9Pb3KC1/hW8j56qymTmxi5yKBjaDnnL1EUcexc=; b=P+szSLsCvMrZen2NueaUnmNXmQHETZDX3919GAPK4rvAf8b1J3OL4OWB6bI6s+sO7w XMa6MKVFABJmUZ0phPJA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YCwbm3G9obgAK+fQP43wonYY1UTeZusb/5rSJt19DaDQzW+0o6uOUpqE7Cfca1UbZx uQUryNcUXBWqKTC4ISxQ== MIME-Version: 1.0 Received: by 10.142.212.10 with SMTP id k10mr2163661wfg.70.1298680570369; Fri, 25 Feb 2011 16:36:10 -0800 (PST) Received: by 10.142.213.7 with HTTP; Fri, 25 Feb 2011 16:36:10 -0800 (PST) In-Reply-To: <593793.24331.qm@web55801.mail.re3.yahoo.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> <593793.24331.qm@web55801.mail.re3.yahoo.com> Date: Fri, 25 Feb 2011 16:36:10 -0800 Message-ID: From: Brian Eaton To: fcorella@pomcor.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Sat, 26 Feb 2011 02:46:33 -0800 Cc: "websec@ietf.org" , OAuth Mailing List , "Karen P. Lewison" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 00:35:26 -0000 I don't think the advice from the OAuth 1.0a spec is wrong: http://oauth.net/core/1.0a/#anchor38 "Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. Service Providers SHOULD strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the User at the Consumer site intended to complete the OAuth negotiation with the Service Provider." This is the purpose of the "state" parameter during the approval flows. Cheers, Brian On Fri, Feb 25, 2011 at 3:42 PM, Francisco Corella wr= ote: > > Hi James, > > You raise an interesting point.=A0 I hadn't thought about the > threat of 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=82=C4=F4s server issues the attacker=82=C4=F4s credentials = to a > > client app ... > > But how will the client app get the "credentials" (bearer token) > from the wrong authorization server? > > Even though the particular attack you describe may not work, > OAuth is wide open to Login CSRF in a different way.=A0 An > attacker can legitimately obtain an authorization code, and > then cause the victim's browser to submit it to the client > application, thus logging the victim in to the client > application as the attacker (in a social login scenario such > as "log in with Facebook").=A0 I bet all applications that use > OAuth to delegate authentication (to Facebook, Twitter, > Google, LinkedIn, Yahoo, etc.) are vulnerable to this now. > > One solution I would propose is to have the client set a > pre-session cookie in the user's browser before the first > redirection and include the value of the cookie in the local > state parameter that it sends to the authorization server. > The authorization server later returns the local state > together with the authorization code, and the browser adds > the cookie, so the client can prevent the attack by checking > that the value of the cookie agrees with the value it > included in the local state. > > Francisco > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Sat Feb 26 04:26:21 2011 Return-Path: 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 ) 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 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" 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" , OAuth Mailing List 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 12:26:21 -0000 This is a multi-part message in MIME format. --------------030004040703060504060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------030004040703060504060508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
--------------030004040703060504060508-- From James.H.Manger@team.telstra.com Sun Feb 27 18:18:30 2011 Return-Path: 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 736473A6961 for ; Sun, 27 Feb 2011 18:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 EpjSvQwC+SVW for ; Sun, 27 Feb 2011 18:18:29 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 6AC023A6A57 for ; Sun, 27 Feb 2011 18:18:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,237,1296997200"; d="scan'208";a="26405353" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 28 Feb 2011 13:19:27 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6270"; a="20146369" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcdvi.tcif.telstra.com.au with ESMTP; 28 Feb 2011 13:19:27 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 28 Feb 2011 13:19:26 +1100 From: "Manger, James H" To: Adam Barth , "websec@ietf.org" Date: Mon, 28 Feb 2011 13:19:25 +1100 Thread-Topic: [websec] Indicating origin of OAuth credentials to combat login CSRF Thread-Index: AcvVhDZuebDVjch7TmW/2L7IGMnuwgBXSkeA Message-ID: <255B9BB34FB7D647A506DC292726F6E1127ECCD305@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 02:18:30 -0000 >On Thu, Feb 24, 2011 at 4:08 PM, Manger, James H > wrote: >> Q. Should an OAuth client app list the authorization server in the Origi= n >> header of requests to resource servers? Adam Barth replied: > 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. That is true, Adam, but I was hoping for a bit more advice from the group k= nowing most about "Origin" and cross-site requests about the need to indica= te the server that dynamically provided an opaque value that the client is = putting in the Authorization header of subsequent cross-origin requests. Once specific question for websec is: What semantics are associated with the *order* of origins in an "Origin" HT= TP request header value? The Origin spec implies (but doesn't explain) that there is some meaning to= the order: a duplicate origin is omitted if it would be next to the same v= alue (but included if there are intervening origins); and a site returning = a redirect is appended to existing origins. CORS seems to ignore the order of origins for non-preflight requests [http:= //www.w3.org/TR/cors/#resource-requests section 5.1 step 2]. CORS seems to imply a preflight request can only have a single origin in it= s "Origin" header [section 5.2 step 2]. That might not work well if OAuth s= ays the authorization server shall be indicated in the "Origin" header as w= ell. Perhaps it would be better for the Origin header to be specified as a *set*= of origins, not a list. That is, state that order doesn't matter (and no d= uplicates are allowed). Would that hinder any uses of Origin? I suspect open redirectors are the problem. After a redirect, the origin of= the original request no longer has any influence over the subsequent reque= st so, theoretically, they should be dropped from the Origin header. In pra= ctise, that is only secure if trusted sites do not have open redirectors --= that might be too much to hope for. It seems to me that the Origin spec is keeping the pre-redirect origins to = cope with open redirectors, and implicitly hoping the order of origins can = be used to ignore all but the last origin when necessary. Such an unstated = hope interacts badly if OAuth adds an origin that isn't from a redirect. -- James Manger From ietf@adambarth.com Sun Feb 27 21:46:45 2011 Return-Path: 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 839723A6AB8 for ; Sun, 27 Feb 2011 21:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 mFQzeL2TAJty for ; Sun, 27 Feb 2011 21:46:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2587D3A686D for ; Sun, 27 Feb 2011 21:46:44 -0800 (PST) Received: by iyj8 with SMTP id 8so2931403iyj.31 for ; Sun, 27 Feb 2011 21:47:43 -0800 (PST) Received: by 10.231.59.213 with SMTP id m21mr5172738ibh.24.1298872062841; Sun, 27 Feb 2011 21:47:42 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id z4sm4184675ibg.7.2011.02.27.21.47.41 (version=SSLv3 cipher=OTHER); Sun, 27 Feb 2011 21:47:41 -0800 (PST) Received: by iyj8 with SMTP id 8so2931384iyj.31 for ; Sun, 27 Feb 2011 21:47:41 -0800 (PST) Received: by 10.42.177.137 with SMTP id bi9mr4541082icb.107.1298872061154; Sun, 27 Feb 2011 21:47:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.40.7 with HTTP; Sun, 27 Feb 2011 21:47:11 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127ECCD305@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127ECCD305@WSMSG3153V.srv.dir.telstra.com> From: Adam Barth Date: Sun, 27 Feb 2011 21:47:11 -0800 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 05:46:45 -0000 On Sun, Feb 27, 2011 at 6:19 PM, Manger, James H wrote: >>On Thu, Feb 24, 2011 at 4:08 PM, Manger, James H >> wrote: >>> Q. Should an OAuth client app list the authorization server in the Orig= in >>> header of requests to resource servers? > > Adam Barth replied: >> They are allowed to, but are not required to, by the Origin header >> specification. =A0Whether they should or not is a question for the OAuth >> working group to decide. > > That is true, Adam, but I was hoping for a bit more advice from the group= knowing most about "Origin" and cross-site requests about the need to indi= cate the server that dynamically provided an opaque value that the client i= s putting in the Authorization header of subsequent cross-origin requests. I'm not familiar enough with the details of OAuth to give you a meaningful answer. Last time I looked into Login CSRF issues with OAuth, the protocol had a large problem and every implementation I experimented with was trivially vulnerable. I'd certainly recommend doing something to prevent those attacks, but I'm unsure to what extent the Origin header is the best solution available to you. > Once specific question for websec is: > What semantics are associated with the *order* of origins in an "Origin" = HTTP request header value? There are no semantics associated with the order of origins in the Origin header. To wit: http://tools.ietf.org/html/draft-ietf-websec-origin-00#section-6.2 [[ 6.2. Semantics When included in an HTTP request, the Origin header indicates the origin(s) that caused the user agent to issue the request. For example, consider a user agent that executes scripts on behalf of origins. If one of those scripts causes the user agent to issue an HTTP request, the user agent might wish to use the Origin header to inform the server that the request was issued by the script. In some cases, a number of origins contribute to causing the user agents to issue an HTTP request. In those cases, the user agent can list all the origins in the Origin header. For example, if the HTTP request was initially issued by one origin but then later redirected by another origin, the user agent might wish to inform the server that two origins were involved in causing the user agent to issue the request. ]] Notice that the semantics does not depend on the order. > The Origin spec implies (but doesn't explain) that there is some meaning = to the order: a duplicate origin is omitted if it would be next to the same= value (but included if there are intervening origins); and a site returnin= g a redirect is appended to existing origins. Those are user agent requirement for generating the header and not related to the semantics, which are defined in Section 6.2. > CORS seems to ignore the order of origins for non-preflight requests [htt= p://www.w3.org/TR/cors/#resource-requests section 5.1 step 2]. > CORS seems to imply a preflight request can only have a single origin in = its "Origin" header [section 5.2 step 2]. That might not work well if OAuth= says the authorization server shall be indicated in the "Origin" header as= well. > > Perhaps it would be better for the Origin header to be specified as a *se= t* of origins, not a list. That is, state that order doesn't matter (and no= duplicates are allowed). Would that hinder any uses of Origin? However we model the semantics of the header, when serialized on the wire the origins will appear in some textual order. The document simple defines precisely how user agents ought to generate that serialization. > I suspect open redirectors are the problem. After a redirect, the origin = of the original request no longer has any influence over the subsequent req= uest so, theoretically, they should be dropped from the Origin header. In p= ractise, that is only secure if trusted sites do not have open redirectors = -- that might be too much to hope for. > > It seems to me that the Origin spec is keeping the pre-redirect origins t= o cope with open redirectors, and implicitly hoping the order of origins ca= n be used to ignore all but the last origin when necessary. Such an unstate= d hope interacts badly if OAuth adds an origin that isn't from a redirect. I didn't follow these paragraphs. The specification is quite clear about how the Origin header interacts with semantics. If you have specific questions, I can try to answer them, but I'm not sure there's as specific a teleology as you ascribe above. Adam From James.H.Manger@team.telstra.com Sun Feb 27 22:53:22 2011 Return-Path: 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 DF7263A68F2 for ; Sun, 27 Feb 2011 22:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 HCjFAqYekT75 for ; Sun, 27 Feb 2011 22:53:21 -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 6836F3A6804 for ; Sun, 27 Feb 2011 22:53:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,238,1296997200"; d="scan'208";a="29785744" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 28 Feb 2011 17:54:18 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6270"; a="20676292" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcani.tcif.telstra.com.au with ESMTP; 28 Feb 2011 17:54:18 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Mon, 28 Feb 2011 17:54:17 +1100 From: "Manger, James H" To: Adam Barth , "websec@ietf.org" Date: Mon, 28 Feb 2011 17:54:15 +1100 Thread-Topic: [websec] Indicating origin of OAuth credentials to combat login CSRF Thread-Index: AcvXCwX3m4LwPlzkQGOtaq877n7QAQAAFm+g Message-ID: <255B9BB34FB7D647A506DC292726F6E1127F341E67@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127ECCD305@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 06:53:23 -0000 Thanks Adam. >> What semantics are associated with the *order* of origins in an "Origin"= HTTP request header value? > There are no semantics associated with the order of origins in the Origin= header. Great. >> The Origin spec implies (but doesn't explain) that there is some meaning= to the order: a duplicate origin is omitted if it would be next to the sam= e value (but included if there are intervening origins); and a site returni= ng a redirect is appended to existing origins. > Those are user agent requirement for generating the header and not related to the semantics, which are defined in Section 6.2. Ok, sort of. So the text "no two consecutive serialized-origin productions in the grammar can be i= dentical" includes the word "consecutive" not for any semantic meaning, but because y= ou think it might be easier for user-agents to implement the spec if they o= nly have to compare an origin they are adding against the last existing ori= gin, not all existing origins? I can image a server X that is happy to accept a request redirected from a = trusted server Y even if the request was originally caused by an unknown se= rver Z. X totally trusts Y -- to not issue CSRF attacks, and to not be a co= nduit for CSRF attacks. However, when X receives Origin: Z Y can it safely accept the request? Not according to the semantics (6.2.) as unknown Z was somehow involved. But it can be safe once 6.3 is also considered since any (potentially malic= ious) redirect from the unknown Z to X could not produce this ordering (it = could produce "Origin: Y Z"). Giving user-agents precise instructions (MUSTs) is nice, but it does add se= mantics. -- James Manger From ietf@adambarth.com Sun Feb 27 23:02:56 2011 Return-Path: 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 BC2C43A69ED for ; Sun, 27 Feb 2011 23:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 pIwFZEERpPST for ; Sun, 27 Feb 2011 23:02:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id DC2953A6804 for ; Sun, 27 Feb 2011 23:02:54 -0800 (PST) Received: by iyj8 with SMTP id 8so2974895iyj.31 for ; Sun, 27 Feb 2011 23:03:54 -0800 (PST) Received: by 10.42.229.74 with SMTP id jh10mr2861583icb.341.1298876634310; Sun, 27 Feb 2011 23:03:54 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id d21sm4260952ibg.21.2011.02.27.23.03.53 (version=SSLv3 cipher=OTHER); Sun, 27 Feb 2011 23:03:53 -0800 (PST) Received: by iyj8 with SMTP id 8so2974880iyj.31 for ; Sun, 27 Feb 2011 23:03:53 -0800 (PST) Received: by 10.231.16.200 with SMTP id p8mr5117391iba.181.1298876633057; Sun, 27 Feb 2011 23:03:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.40.7 with HTTP; Sun, 27 Feb 2011 23:03:23 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127F341E67@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127ECCD305@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127F341E67@WSMSG3153V.srv.dir.telstra.com> From: Adam Barth Date: Sun, 27 Feb 2011 23:03:23 -0800 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 07:02:57 -0000 On Sun, Feb 27, 2011 at 10:54 PM, Manger, James H wrote: > Thanks Adam. > >>> What semantics are associated with the *order* of origins in an "Origin= " HTTP request header value? >> There are no semantics associated with the order of origins in the Origi= n header. > > Great. > >>> The Origin spec implies (but doesn't explain) that there is some meanin= g to the order: a duplicate origin is omitted if it would be next to the sa= me value (but included if there are intervening origins); and a site return= ing a redirect is appended to existing origins. > >> Those are user agent requirement for generating the header and not > related to the semantics, which are defined in Section 6.2. > > Ok, sort of. > So the text > =A0"no two consecutive serialized-origin productions in the grammar can b= e identical" > includes the word "consecutive" not for any semantic meaning, but because= you think it might be easier for user-agents to implement the spec if they= only have to compare an origin they are adding against the last existing o= rigin, not all existing origins? That's just syntax. Specifically, that sentence is restricting the syntax that user agents can generate to a subset of the syntax generated by the grammar. > I can image a server X that is happy to accept a request redirected from = a trusted server Y even if the request was originally caused by an unknown = server Z. X totally trusts Y -- to not issue CSRF attacks, and to not be a = conduit for CSRF attacks. However, when X receives > =A0Origin: Z Y > can it safely accept the request? I'm not sure you've provided enough information in this hypothetical, but I suspect the answer is no. > Not according to the semantics (6.2.) as unknown Z was somehow involved. Indeed. In addition, without something like a Cookie, the HTTP request might have originated from the attacker's computer and not from a compliant user agent. > But it can be safe once 6.3 is also considered since any (potentially mal= icious) redirect from the unknown Z to X could not produce this ordering (i= t could produce "Origin: Y Z"). I'm not sure that's accurate. > Giving user-agents precise instructions (MUSTs) is nice, but it does add = semantics. The semantics are whatever we define them to be. In this case, we've defined the semantics to be order independent. Adam