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

Adam Barth <ietf@adambarth.com> Wed, 18 July 2012 23:16 UTC

Return-Path: <ietf@adambarth.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 A82ED11E81C3 for <websec@ietfa.amsl.com>; Wed, 18 Jul 2012 16:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6efut3l3ZPY for <websec@ietfa.amsl.com>; Wed, 18 Jul 2012 16:16:44 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5891911E81C2 for <websec@ietf.org>; Wed, 18 Jul 2012 16:16:44 -0700 (PDT)
Received: by yhq56 with SMTP id 56so2405893yhq.31 for <websec@ietf.org>; Wed, 18 Jul 2012 16:17:35 -0700 (PDT)
Received: by 10.236.138.230 with SMTP id a66mr2621848yhj.91.1342653455613; Wed, 18 Jul 2012 16:17:35 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id r25sm709226yhi.13.2012.07.18.16.17.33 (version=SSLv3 cipher=OTHER); Wed, 18 Jul 2012 16:17:34 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so3251796obb.31 for <websec@ietf.org>; Wed, 18 Jul 2012 16:17:32 -0700 (PDT)
Received: by 10.182.110.102 with SMTP id hz6mr3787913obb.79.1342653452958; Wed, 18 Jul 2012 16:17:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.226.5 with HTTP; Wed, 18 Jul 2012 16:17:02 -0700 (PDT)
In-Reply-To: <68291699F5EA8848B0EAC2E78480571F053A3186@TK5EX14MBXC216.redmond.corp.microsoft.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>
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 18 Jul 2012 16:17:02 -0700
Message-ID: <CAJE5ia90hJ7EQDgn7Y3u2m1Lxe=fwkG65YE7YtiBNJfDtaE0rA@mail.gmail.com>
To: David Ross <dross@microsoft.com>
Content-Type: multipart/alternative; boundary="f46d04447f4b1ebb4804c522dec3"
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: Wed, 18 Jul 2012 23:16:45 -0000

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:

http://code.google.com/chrome/extensions/contentSecurityPolicy.html

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.

Adam


On Wed, Jul 11, 2012 at 5:22 PM, David Ross <dross@microsoft.com> 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
> dross@microsoft.com
>
>
> -----Original Message-----
> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf
> Of Hill, Brad
> Sent: Monday, July 09, 2012 5:03 PM
> To: Tobias Gondrom; websec@ietf.org
> Cc: public-webappsec@w3.org
> Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety
> directives
>
> Tobias,
>
>  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@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>