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

David Ross <> Thu, 19 July 2012 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C58A21F86EB for <>; Thu, 19 Jul 2012 12:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BpWVZYgU3P9Y for <>; Thu, 19 Jul 2012 12:50:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C9F7911E8098 for <>; Thu, 19 Jul 2012 12:50:42 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Thu, 19 Jul 2012 19:51:36 +0000
Received: from mail252-va3 (localhost []) by (Postfix) with ESMTP id 397924800FC for <>; Thu, 19 Jul 2012 19:51:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -41
X-BigFish: VS-41(zz98dI9371Ic85fh542M1418I604T1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah)
Received-SPF: pass (mail252-va3: domain of designates as permitted sender) client-ip=;; ; ;
X-Forefront-Antispam-Report-Untrusted: CIP:; KIP:(null); UIP:(null); (null);; R:internal; EFV:INT
Received: from mail252-va3 (localhost.localdomain []) by mail252-va3 (MessageSwitch) id 1342727494723546_9654; Thu, 19 Jul 2012 19:51:34 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id AEDC31CC0045 for <>; Thu, 19 Jul 2012 19:51:34 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 19 Jul 2012 19:51:33 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 19 Jul 2012 19:51:29 +0000
Received: from ( by ( with Microsoft SMTP Server id; Thu, 19 Jul 2012 19:51:20 +0000
Received: from mail66-va3 (localhost []) by (Postfix) with ESMTP id 878F8220365 for <>; Thu, 19 Jul 2012 19:51:19 +0000 (UTC)
Received: from mail66-va3 (localhost.localdomain []) by mail66-va3 (MessageSwitch) id 1342727477491658_27105; Thu, 19 Jul 2012 19:51:17 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 6725032004B; Thu, 19 Jul 2012 19:51:17 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 19 Jul 2012 19:51:16 +0000
Received: from ([]) by ([]) with mapi id 14.16.0175.005; Thu, 19 Jul 2012 19:51:14 +0000
From: David Ross <>
To: Adam Barth <>, Tobias Gondrom <>
Thread-Topic: [websec] Coordinating Frame-Options and CSP UI Safety directives
Thread-Index: Ac1eARMykz8Gk35PQYOw0F4CVEc1fgAKMP0AAAFdb4AAZMpUwAFePnIAACpPKLA=
Date: Thu, 19 Jul 2012 19:51:14 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9B5348748B708948989B17CC0AEA3DD0027A848ASN2PRD0310MB395_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
X-Mailman-Version: 2.1.12
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: Thu, 19 Jul 2012 19:50:48 -0000

#1 - fair point
#2 - I was worried that the current mechanism was multi-origin only, but it sounds like that's not the case.  If so, this is good.

NIH doesn't sound like a great reason at all.

Question for Tobias -- with a move to push this from the IETF to the W3C/CSP, given your IETF affiliation would you still be able to contribute time to this project?  (Sorry if that's an exceedingly blunt question, I'm not trying to step on toes here.)  Your work here thus far has been absolutely invaluable and has allowed XFO/FO to make forward progress with very little overhead.  I really don't want to lose the momentum.


From: Adam Barth []
Sent: Wednesday, July 18, 2012 4:17 PM
To: David Ross
Cc: Hill, Brad; Tobias Gondrom;
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

Here are two reasons we should make Frame-Options into a Content-Security-Policy directive rather than yet-another-one-off-HTTP-header:

1) By centralizing all the policy bits in one string, we gain network benefits.  For example, in the Chrome extension system, we have a field in the manifest for specifying a Content Security Policy:

While we could add a new attribute for every different bit of policy, it's better for developers if there's just one place that contains the security policy.

2) By moving Frame-Options into CSP, we can use the same origin-specifying machinery that already exists in CSP rather than inventing yet-another-way-of-specifying origins (e.g., in allow-from in the current Frame-Options draft).  By doing that, we make all these things work the same way rather than siloing each off depending on which browser vendor first decided this bit of policy was interesting.

As far as I can tell, the main reason for not making Frame-Options a CSP directive is that CSP was Not Invented Here.


On Wed, Jul 11, 2012 at 5:22 PM, David Ross <<>> wrote:
Responding to a few of the points in Brad's original mail on this thread...

My concern is mostly around the degree to which a move to CSP might complicate or stall the process.  I'd also prefer not to see additional use cases pop up (eg: click fraud prevention) that just were never in scope before.

I think that w.r.t. header bloat, the most sensible approach is to only allow one origin to be specified.  CSP by-design facilitates the use of multiple origins.  As we've discussed w/Frame-Options, there is a design pattern to make the more basic single-origin approach functional.  I would hate to see hosts serving up source lists of hundreds of origins, just because they can.  I think that is exactly what will happen if we support multiple origins.

With regard to obsolescence of X-FRAME-OPTIONS, it's easy to specify exactly what happens in the FRAME-OPTIONS spec.  I don't see that CSP inherently improves on that but I may be missing something there.

The advantage I see of bringing FRAME-OPTIONS into CSP is that it makes CSP more comprehensive.  But I suspect there are plenty of other header-related security features that aren't defined by CSP (eg: the origin header, cookie security).

Finally, as Brad pointed out in the rosetta stone thread, Frame-Options provides the flexibility to perform only a top level origin check as opposed to a full ancestor check.  (Specified via the "AllAncestors" flag.)

David Ross<>

-----Original Message-----
From:<> [<>] On Behalf Of Hill, Brad
Sent: Monday, July 09, 2012 5:03 PM
To: Tobias Gondrom;<>
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives


 I'm happy to move the discussion primarily to websec, and I'll drop the cc: to webappsec after this email.  Thanks for the historical clarification, as well.

I'm not terribly concerned about which group does the work, as much as arriving at the engineering solution that works best for user agent and resource authors, some of whom have expressed preference for moving this functionality into CSP.  As both a chair and an individual, I don't have a strong preference, but I think there are reasons in favor of each option and it is worth re-opening the discussion now that the WebAppSec WG has a concrete deliverable under development to address the same general class of attacks.

I'll send out a summary shortly of the similarities and differences between the various options currently proposed for some additional context.

-Brad Hill

websec mailing list<>

websec mailing list<>