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

=JeffH <> Fri, 13 July 2012 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77E1D11E80BC for <>; Thu, 12 Jul 2012 17:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.457
X-Spam-Status: No, score=-100.457 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fb6hBjfvBKIO for <>; Thu, 12 Jul 2012 17:29:33 -0700 (PDT)
Received: from ( [IPv6:2605:dc00:100:2::a5]) by (Postfix) with SMTP id 9DE1F11E8098 for <>; Thu, 12 Jul 2012 17:29:33 -0700 (PDT)
Received: (qmail 27540 invoked by uid 0); 13 Jul 2012 00:30:08 -0000
Received: from unknown (HELO ( by with SMTP; 13 Jul 2012 00:30:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=jv1uFmwIL9ERb36vrsOEMNfCvdQsfm7z130yvqLrVBo=; b=BWf6Cpq9NSvjLbAyhhc+hlwy0swMloK+jvmXgBkv1sho8JTYmqV2Got68+6irc/bTEaj8+LlLSSXlR2h6K5WGfS5HovJr3mASt7zsEK5InMoMBlAWZsvmqaDv3+F25of;
Received: from [] (port=17898 helo=[]) by with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <>) id 1SpTlm-0001P7-7K; Thu, 12 Jul 2012 18:30:06 -0600
Message-ID: <>
Date: Thu, 12 Jul 2012 17:30:04 -0700
From: =JeffH <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: David Ross <>, IETF WebSec WG <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {} {sentby:smtp auth authed with}
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: Fri, 13 Jul 2012 00:29:34 -0000

thanks for your thoughts Dave,

 > My concern is mostly around the degree to which a move to CSP might
 > complicate or stall the process.

by this I presume you mean the process of producing a spec for a standardized 
"frame-options" (i.e., the successor to "x-frame-options").

I don't think leveraging CSP as a framework, per se, would necessarily slow this 

 >  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 it's reasonable to discuss whether the "frame-options" policy directive 
(aka "frame-ancestors", "embed-ancestors") should be specified as a part of the 
nascent "UI Safety directives" spec (in W3C WebAppSec), or the CSP 1.1 spec (in 
W3C WebAppSec), or as a stand-alone spec.

 > I think that w.r.t. header bloat,

Ah, so there's two aspects to "header bloat" in this discussion..

1. "header bloat" in relation to possibly defining yet another HTTP header field 
to convey a security policy, i.e. a stand-alone "frame-options" header field.

2. "header value bloat" in terms of having a header field into which server 
operators may feel obliged to cram a huge list of items (i.e., origins).

 From a high-level perspective, casting "frame-options" as a CSP directive 
works towards addressing (1).

 > the most sensible approach is to only allow one origin to be specified.

And this statement is addressing (2).

 > CSP by-design facilitates the use of multiple origins.

However, the ABNF of any particular CSP directive can be crafted in order to 
allow only one origin to be specified as a value, e.g. like so..

   directive-name  = "frame-options"
   directive-value = host-source

[ where host-source is defined as..

   host-source       = [ scheme "://" ] host [ port ]

 > As we've discussed w/Frame-Options, there is a design pattern to
 > make the more basic single-origin approach functional.


(fwiw, I'd term what you're calling a "design pattern" as a "implementation and 
deployment technique")

 > 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.

regardless of which specification vehicle we use for the "frame-options" policy 
directive, we'll be able to denote (in some fashion) that it supersedes the old 
"x-frame-options" header. (this is going to be somewhat messy in any case)

 > 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).

well, of course CSP doesn't encompass "everything" and isn't intended to. But we 
certainly should be carefully considering consolidating  policy directive 
conveyance as appropriate, and the "frame-options" (aka "frame-ancestors", 
"embed-ancestors") notion seems to fall reasonably within the "content security 
policy" space -- a key aspect being that it is regarding a particular resource 
representation (as I presently understand it).

 > 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.)

Well, the "AllAncestors" flag can certainly be added to a CSP-based 
"frame-options" policy directive. e.g. by defining a new "keyword-source" of