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

"Hill, Brad" <bhill@paypal-inc.com> Mon, 09 July 2012 18:31 UTC

Return-Path: <bhill@paypal-inc.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BFAFB11E8102 for <websec@ietfa.amsl.com>; Mon, 9 Jul 2012 11:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.117
X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tagpngCvhuPv for <websec@ietfa.amsl.com>; Mon, 9 Jul 2012 11:31:22 -0700 (PDT)
Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com []) by ietfa.amsl.com (Postfix) with ESMTP id DF57611E80D0 for <websec@ietf.org>; Mon, 9 Jul 2012 11:31:21 -0700 (PDT)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:x-ems-proccessed: x-ems-stamp:Content-Type:Content-Transfer-Encoding: MIME-Version; b=KfG98yQuqdi0OYPEUlcJaG4V4PMM063umW/EyuO52cQxGP/qydm0OM8j 8igDBLP9xWabFJUYGijZsxdVEvBqN7wwlJ9a7ItAN6R0wIDHYcKJjD/RP mojy2xKiaV77vFF;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1341858707; x=1373394707; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Z/n+mwRd1Crj5gMvpEzmflV57LLy58HzdV1B+c2fWuY=; b=Byrre7KQbcG3eI74UfUbUHR6lqW1mNpccToDec3YoFnRBREbO2jT1IN2 MN8XBfE7nwccrFJcTLnxPWjl5V+cfGL2YuQBmGSYMD/rkw08j46GmgQLA bi6ouYJ1bRCO3tH;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.77,553,1336374000"; d="scan'208";a="8566207"
Received: from den-exmht-002.corp.ebay.com ([]) by den-mipot-001.corp.ebay.com with ESMTP/TLS/AES128-SHA; 09 Jul 2012 11:31:46 -0700
Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-002.corp.ebay.com ([fe80::cbe:ffa5:17f0:a24a%14]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 12:31:43 -0600
From: "Hill, Brad" <bhill@paypal-inc.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>, "websec@ietf.org" <websec@ietf.org>
Thread-Topic: Coordinating Frame-Options and CSP UI Safety directives
Thread-Index: Ac1eARMykz8Gk35PQYOw0F4CVEc1fg==
Date: Mon, 09 Jul 2012 18:31:42 +0000
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E1799AD@DEN-EXDDA-S12.corp.ebay.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: ILKGZFO3M7NqUlNocZS6Bw==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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: Mon, 09 Jul 2012 18:31:24 -0000

Tobias, David and other WebSec participants,

 Over at the W3C WebAppSec WG we are beginning to draft a set of new directives for Content Security Policy focused specifically on User Interface Safety - protection against clickjacking and other UI Redressing attacks.

 As Adam Barth suggested on this list a few weeks ago, WebSec and WebAppSec should discuss and coordinate on whether new functionality related to UI embedding, such as ALLOW-FROM or embed-ancestors, would be best developed as CSP directives or in a new Frame-Options header.  

 It made sense for the IETF WebSec group to be the lightest and fastest process to specify the existing behavior of X-Frame-Options, but further refinements are more in the realm of web user agent behavior.  If sites are going to specify UI safety directives using CSP, using that mechanism rather than a new Frame-Options header can save on some header bloat, as well as making it easier to interpret scenarios where a resource wants to obsolete the X-Frame-Options when new behaviors are available. (e.g., allow embedding if CSP UI Safety directives are understood, but deny it for user agents that only understand X-Frame-Options)

The current editor's draft doesn't include these options, but please take a look.  


A proposed additional directive for this specification is:


The embed-options directive indicates whether the user-agent should embed the resource using a frame, iframe, object or embed tag, or equivalent functionality in non-HTML resources. Resources can use this to avoid many UI Redressing attacks by ensuring they are not embedded into other sites. This directive replicates some of the functionality of the X-Frame-Options header. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "embed-ancestors"
directive-value   = source-list

Unlike policies defined in Content Security Policy 1.0, the embed-ancestors directives is not subject to the default-src directive. If this directive is not explicitly stated in the policy its value is assumed to be "*". 

If 'deny' is present in the source-list, the resource cannot be displayed in an embedded context, regardless of the origin attempting to do so, and all other members of the source-list are ignored. This provides functionality equivalent to the DENY value of the X-Frame-Options header.

If 'deny' is not present the source-list indicates which origins are valid ancestors for the resource. An ancestor is any resource between the protected resource and the top of the window frame tree; for example, if A embeds B which embeds C, both A and B are ancestors of C. If A embeds both B and C, B is not an ancestor of C, but A still is.

The 'self' source indicates that content of the same-origin as the protected resource may embed it. This provides functionality equivalent to the SAMEORIGIN value of the X-Frame-Options header.

Thank you - we welcome your thoughts and feedback,

 Brad Hill
Co-chair, W3C WebAppSec WG