Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

David Ross <dross@microsoft.com> Tue, 04 September 2012 05:06 UTC

Return-Path: <dross@microsoft.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4B921F8540 for <websec@ietfa.amsl.com>; Mon, 3 Sep 2012 22:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.133
X-Spam-Level: **
X-Spam-Status: No, score=2.133 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aciXX2s5r+BJ for <websec@ietfa.amsl.com>; Mon, 3 Sep 2012 22:06:51 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 535B921F848B for <websec@ietf.org>; Mon, 3 Sep 2012 22:06:48 -0700 (PDT)
Received: from mail92-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 05:06:47 +0000
Received: from mail92-co1 (localhost [127.0.0.1]) by mail92-co1-R.bigfish.com (Postfix) with ESMTP id 78D9D580093 for <websec@ietf.org>; Tue, 4 Sep 2012 05:06:47 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -52
X-BigFish: VS-52(zzbb2dI98dI9371I542M1432Ib08R604T14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah107ah1220h1155h)
Received-SPF: pass (mail92-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dross@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ;
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.5; KIP:(null); UIP:(null); (null); H:SN2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT
Received: from mail92-co1 (localhost.localdomain [127.0.0.1]) by mail92-co1 (MessageSwitch) id 1346735204974845_9252; Tue, 4 Sep 2012 05:06:44 +0000 (UTC)
Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.229]) by mail92-co1.bigfish.com (Postfix) with ESMTP id EA193600046 for <websec@ietf.org>; Tue, 4 Sep 2012 05:06:44 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 05:06:44 +0000
Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 4 Sep 2012 05:06:42 +0000
Received: from mail238-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 05:06:42 +0000
Received: from mail238-tx2 (localhost [127.0.0.1]) by mail238-tx2-R.bigfish.com (Postfix) with ESMTP id 26C69880207 for <websec@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Tue, 4 Sep 2012 05:06:42 +0000 (UTC)
Received: from mail238-tx2 (localhost.localdomain [127.0.0.1]) by mail238-tx2 (MessageSwitch) id 1346735200673698_29895; Tue, 4 Sep 2012 05:06:40 +0000 (UTC)
Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.254]) by mail238-tx2.bigfish.com (Postfix) with ESMTP id 9565FC20044; Tue, 4 Sep 2012 05:06:40 +0000 (UTC)
Received: from SN2PRD0310HT001.namprd03.prod.outlook.com (157.56.234.5) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 05:06:39 +0000
Received: from SN2PRD0310MB395.namprd03.prod.outlook.com ([169.254.3.203]) by SN2PRD0310HT001.namprd03.prod.outlook.com ([10.255.112.36]) with mapi id 14.16.0190.008; Tue, 4 Sep 2012 05:06:39 +0000
From: David Ross <dross@microsoft.com>
To: Adam Barth <ietf@adambarth.com>, Tobias Gondrom <tobias.gondrom@gondrom.org>
Thread-Topic: [websec] Coordinating Frame-Options and CSP UI Safety directives
Thread-Index: Ac1eARMykz8Gk35PQYOw0F4CVEc1fgAKMP0AAAFdb4AAZMpUwAFePnIAACpPKLAAInNOAAikUYAAAAhkJwAANDDUgAABw6cAABdbLXA=
Date: Tue, 4 Sep 2012 05:06:39 +0000
Message-ID: <9B5348748B708948989B17CC0AEA3DD002A59B4C@SN2PRD0310MB395.namprd03.prod.outlook.com>
References: <370C9BEB4DD6154FA963E2F79ADC6F2E1799AD@DEN-EXDDA-S12.corp.ebay.com> <4FFB67EE.406@gondrom.org> <370C9BEB4DD6154FA963E2F79ADC6F2E17AE18@DEN-EXDDA-S12.corp.ebay.com> <68291699F5EA8848B0EAC2E78480571F053A3186@TK5EX14MBXC216.redmond.corp.microsoft.com> <CAJE5ia90hJ7EQDgn7Y3u2m1Lxe=fwkG65YE7YtiBNJfDtaE0rA@mail.gmail.com> <9B5348748B708948989B17CC0AEA3DD0027A848A@SN2PRD0310MB395.namprd03.prod.outlook.com> <043AA6DA-9D3F-4EC2-B5D4-E1FF2FD0F470@w3.org> <504345AC.5050800@gondrom.org> <CAJE5ia_xpki2+WHD9KCmNJCW_WrrRHCRuff5eSxcTnLpWOtSGg@mail.gmail.com> <5044DC3B.7090202@gondrom.org> <CAJE5ia-i-f6Yreogyn4rJwSLbX1qP7t3jJ00LXfyQNa2gsK17Q@mail.gmail.com>
In-Reply-To: <CAJE5ia-i-f6Yreogyn4rJwSLbX1qP7t3jJ00LXfyQNa2gsK17Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.46.102.229]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: SN2PRD0310HT001.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%ADAMBARTH.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GONDROM.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%W3.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com
X-OriginatorOrg: microsoft.com
Cc: "websec@ietf.org" <websec@ietf.org>
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 04 Sep 2012 05:06:53 -0000

There was a bit of discussion earlier on the list w.r.t. multi-origin vs. single-origin for allow-from.  I'm very much in favor of single origin.  Just imagine a few years from now seeing a policy or header with 1500 origins -- if we allow that to happen, it will happen.

So I'm very happy to hear we can specify the single-origin syntax as suggested below.  If we're going to go with CSP for FO, I'd feel most comfortable if we can get some confirmation that this is the POR.

I agree that serving dynamic policy shouldn't be technically difficult.  But I do worry about this in a larger sense.  It would be good to brainstorm implications of dynamic policy.  Is there any impact to platforms, design patterns, etc. that may have been imagined / planned during the course of CSP's development?  It just feels like a non-trivial change to the way CSP was thought out.

Dave

-----Original Message-----
From: Adam Barth [mailto:ietf@adambarth.com] 
Sent: Monday, September 03, 2012 10:26 AM
To: Tobias Gondrom
Cc: websec@ietf.org; tlr@w3.org; David Ross
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

On Mon, Sep 3, 2012 at 9:35 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
> On 02/09/12 23:40, Adam Barth wrote:
>> On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom 
>> <tobias.gondrom@gondrom.org> wrote:
>>>
>>> Hello all,
>>>
>>> thank you for your feedback and input.
>>>
>>> <hat="individual">
>>>
>>> NIH (not invented here) should definitely never be reason for a 
>>> decision
>>> -
>>> in either way.
>>> And I would also be open to assist the WebAppSec WG in writing this 
>>> tiny bit into CSP.
>>>
>>> I have two main reasons why I think we should keep FO separate to 
>>> CSP and would like to hear your thoughts about it before we should 
>>> make a decision.
>>> (Please note that in the case of this topic I will obviously not be 
>>> acting as WG chair.)
>>>
>>> 1. Model and Semantic Reason:
>>> Until now, I always understood the CSP model to be about "describe 
>>> the security policy for a loaded resource and say which parts of 
>>> that content you can execute and which references in that content 
>>> you shall follow and execute".
>>> While the XFO/FO model is the reverse: describing for a resource, 
>>> defining by whom your resource may be framed/loaded from. In my view 
>>> that was not a natural part of the CSP model. And in my 
>>> understanding that semantic difference was also one of the reasons 
>>> why it was not done in CSP1.0 in the first place, but at the time 
>>> agreed to be done in websec separately.
>>
>> Now that we're done with CSP 1.0, I think it make sense to take a 
>> more expansive view of the sorts of security policies that can be 
>> expressed in a Content-Security-Policy.  My view is that a security 
>> policy expressed in CSP ought to have the following properties:
>>
>> 1) The policy should apply only to an individual resource 
>> representation.  That means that the security policy is scoped to the 
>> individual HTTP response and doesn't have broader-reaching effects 
>> (e.g., about future HTTP responses).
>>
>> 2) The policy should only restrict privileges---not grant any 
>> privileges.  That means that the security policy is useful for 
>> implementing "least privilege": you can use it to drop privileges 
>> you're not using (e.g., the ability to execute inline script) so that 
>> an attacker can't trick you into using this privileges to your 
>> detriment.
>>
>> X-Frame-Options / Frame-Options fits nicely into this rubric.
>
> Well. Hm. I am not sure that I would agree that extending the CSP 
> semantic model to the superset that then includes "defining by whom 
> your resource may be framed/loaded from" instead of the current CSP1.0 
> model is necessarily a good thing. Maybe one question: If we extend 
> the semantic of a system, it is always good if such extension is not 
> for a group size of "1" (aka only one individual directive). Therefore 
> my question: Are there other use cases (directives planned for 2.0) 
> that require the same type of semantic extension or would FO be unique 
> in that regard? If so, which semantic extensions would that be?

I'm not sure I understood your question, but I'll try to answer it anyway.  We're considering a number of new directives for CSP 1.1 that aren't related to loading subresources.  For example, the form-action directive is about restricting form submissions:

http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#form-action--experimental

We've designed CSP to be extensible, as requested by <http://tools.ietf.org/html/draft-hodges-websec-framework-reqs-02#section-7>.
 Frame-options falls well inside the scope we envision.

>>> Or as someone else from W3C WebAppSec wrote it more clearly to me 
>>> about a year ago:
>>> "... removing frame-ancestors from CSP altogether if a better, 
>>> standardized Frame-Options is available to sites. In fact, it 
>>> simplifies the model in some ways since frame-ancestors is currently 
>>> the only directive that restricts content from the embedded site's 
>>> perspective."
>>
>> Having a simplified model has been very helpful to us over the past 
>> year because it has let us finish CSP 1.0.  Now we're done with CSP
>> 1.0 and looking at what the next step should be in CSP's evolution.
>>
>>> 2. Technical Implementation:
>>> The current FO spec allows only one "Allow-From" URI. Which means 
>>> that for complex framing relationships, the FO header needs to be 
>>> written/sent on the fly on a per request basis.
>>> My question is, what happens to only one "ALLOW-FROM" if we 
>>> integrate it into CSP?
>>> Can we generate individual CSPs on the fly as well (including if a 
>>> CSP header references a file), or would this then implicitely mean 
>>> we have to allow a list of "ALLOW-FROM"?
>>
>> Integrating with CSP imposes no technical restrictions in this regard.
>>   If you want to have only a single source, you can define the syntax
>> as:
>>
>> directive-name = "frame-options"
>> directive-value = source-expression
>>
>> Most other directives use source-list (which is just a list of 
>> source-expressions), but there's no reason we can't do something 
>> different here if that makes sense.  In fact, the only hard technical 
>> restriction on the directive-value is that it conform to the 
>> following
>> ABNF:
>>
>> directive-value   = *( WSP / <VCHAR except ";" and ","> )
>
> Adam, I am sorry. I may not have been clear enough with my question.
> My concern is not with regard of whether we can define such a 
> directive (in my view this is trivial).
>
> But the question is whether we can practically implement such, or 
> whether there are implementation problems that would forbid (or 
> seriously
> discourage) dynamic generation of a CSP on a per request basis?

There are none that I'm aware of.

> Because that
> would be the consequence of only one single "Allow-From" URI (instead 
> of list).
> Or to put it differently:
> - Have there been successful and scaling implementations of CSP that 
> have generated the CSP header on the fly for every request?

I'm not aware of any in the public world, but I have seen (non-public) implementations that construct the script-src whitelist dynamically based on statically analyzing the HTML templates used to generate a particular page.  You might imagine that this design would be attractive in a system like Google Web Toolkit <https://developers.google.com/web-toolkit/>, where the framework has enough insight into how the app works to build a CSP policy.

> - If not, what would be the pitfalls/problems if we would do so?

There's nothing magical going on.  It's just as easy to generate a Frame-Options header dynamically as it is to generate a frame-options directive in a Content-Security-Policy header dynamically.

> - What are possible performance issues with that?

The performance considerations are the same regardless of whether you're using a Frame-Options header or a frame-options directive in a Content-Security-Policy header.  The two are isomorphic.

> - And last but not least, is there a caching of CSP use case? (which 
> could break if we generate the CSP file on the fly for every single 
> request...)

The Content-Security-Policy header is cached in exactly the same way as the Frame-Options header.  There is nothing magical going on.

> If we move FO to CSP, I would like to know whether this will break (or 
> due to implementation/scaling problems basically forbids) the current 
> design of "Allow-From" _before_ we do so.

It will not.

>>> (please note, that the initial version did allow a list for 
>>> "Allow-From", but there were serious concerns for performance in 
>>> implementation for large lists and privacy matters. The change to 
>>> only one "Allow-From" is not "written in stone", still I would like 
>>> to understand if we limit ourselves back to the "Allow-From list" 
>>> implicitly by putting it into CSP? I had a couple of private 
>>> conversations on this problem in the last months, but they could not 
>>> definitively answer to that question...)
>>
>> I'm a bit surprised that you'd want to limit frame-options to having 
>> only one source-expression, but we can discuss that point regardless 
>> of whether we decide to integrate it with CSP.
>
> Actually, this was not my idea, but from Dave, who explained to me the 
> performance and privacy implications when going with a (potentially 
> long) list of allowed URIs. Personally, I could still see both ("list" or "single"
> URI), though I can understand the very serious concerns with "list".
> We can discuss the FO design decision later, however, as explained 
> above, if the choice to move FO into CSP basically pre-decides that we 
> must then go with a "list" (for practical/implementation reasons), I 
> would like to know and spell out this limitation rather now than later.

Moving to CSP does not imply an pre-decision on this topic.

Adam