[websec] Frame-Options Rosetta Stone (also: frame-ancestors, embed-ancestors)

"Hill, Brad" <bhill@paypal-inc.com> Wed, 11 July 2012 21:35 UTC

Return-Path: <bhill@paypal-inc.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 CCECC11E814B for <websec@ietfa.amsl.com>; Wed, 11 Jul 2012 14:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.117
X-Spam-Level:
X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8]
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 Yh+IWkRXKNvj for <websec@ietfa.amsl.com>; Wed, 11 Jul 2012 14:35:01 -0700 (PDT)
Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id A17DB11E811E for <websec@ietf.org>; Wed, 11 Jul 2012 14:35:01 -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:X-CFilter; b=FXOl7J3PlVGLtnxCDPLWJAwVdXJaRTYS/2noWi9beBWksdOzX+8qOiXo UPu2cJ+bQPZfzmMs/yRNND/zrmU64dNUbVr8CbigDcRriienMmdIFEAk4 xHL4W5LLMWtMRdb;
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=1342042533; x=1373578533; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=7EdTQAeSlILWqFaY2x6V7GJ4y9zfpt2ydsoY0Js7Tow=; b=bJBwzrfW6Xy2fxgt6Xfdns/tKDvf29JM+JzN8xUgve6Ypz958klKh12x g3mbBq1rpTalyvIGvdDkDj3d2QDoluImAwY5+cyvFdJgX99EcnojySV3B a6GCYB7/DSB0yFd;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.77,569,1336374000"; d="scan'208";a="8614056"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 11 Jul 2012 14:35:32 -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; Wed, 11 Jul 2012 15:35:28 -0600
From: "Hill, Brad" <bhill@paypal-inc.com>
To: "websec@ietf.org" <websec@ietf.org>
Thread-Topic: Frame-Options Rosetta Stone (also: frame-ancestors, embed-ancestors)
Thread-Index: Ac1frRWl1G+EwSrATzCVqvzD0wpC/g==
Date: Wed, 11 Jul 2012 21:35:28 +0000
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E17FA96@DEN-EXDDA-S12.corp.ebay.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.245.27.243]
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: AbhjyBw2iBeIf+l3Obq0ZA==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Subject: [websec] Frame-Options Rosetta Stone (also: frame-ancestors, embed-ancestors)
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, 11 Jul 2012 21:35:03 -0000

To add some context to the Frame-Options and CSP UI Safety directives discussion, here's my summary of the current and historical proposals:


HTML-based web applications can embed or "frame" other web applications. Unfortunately, if done in an unrestricted fashion, this can lead to various attacks, both on the embedded/framed application, or on the framing application (the "ancestor"). 

There are various extant, similar approaches to mitigating this, both deployed and proposed, and their names vary somewhat. 

This message is an attempt to list all the various names of, and briefly summarize, each approach. 

The approaches are:

"X-Frame-Options" HTTP response header field

"frame-ancestors" Content Security Policy directive 

"Frame-Options" HTTP response header field

"embed-ancestors"  of Content Security Policy UI Safety directives


Details:

X-Frame-Options:

This was the first widely adopted solution to clickjacking, a header to instruct user agents to disallow embedding a resource in an iframe, or only allow it in top-level resources of the same origin.  Developed independently by Microsoft in Internet Explorer, support for the header has been widely implemented in other browsers.

https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ tracks the status of an effort at the WebSec WG to document the existing behavior of applications setting and user agents supporting X-Frame-Options in an informational-track I-D.  (note: this specification is distinct from the "Frame-options" spec discussed below)

In this draft, the supported parameters are: "DENY", "SAMEORIGIN" and "ALLOW-FROM".

It's behaviors are specified to apply to content embedded through the iframe, frame, and object tags, as well as plugins that "appear essentially as frames".

There is some risk of confusion induced by the fact that the draft includes the "ALLOW-FROM" parameter, which was added after the original X-Frame-Options "specification" (in a couple of posts on blogs.msdn.com) and is not uniformly implemented in the user agent population.  

Current implementations also do not consider "port" as a component of the origin, conflicting with [RFC6454].

Although the draft primarily specifies behavior implemented by web user agents regarding HTML rendering, it was accepted by the WebSec WG of the IETF rather than be developed in the W3C as the goal is primarily to document existing deployed behavior.


Content Security Policy "frame-ancestors" directive:

Early drafts of the W3C Content Security Policy specification proposed a "frame-ancestors" directive with functionality substantially similar to the "ALLOW-FROM" feature of X-Frame-Options, but required that the check be applied to all embedding ancestor resources, not just the origin of the top-level window.  This directive was dropped from the CSP 1.0 as it was felt to be substantially different in character from the other directives in that specification.


Frame-Options:

https://datatracker.ietf.org/doc/draft-ietf-websec-frame-options/   tracks a standards-track effort in the IETF WebSec WG to update and remove the "X-" prefix from X-Frame-Options.  The behavior specified is substantially similar with the addition of an optional "AllAncestors" flag which requires the same behavior as the "frame-ancestors" directive of CSP.


Content Security Policy UI Safety directives:

http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html  is the latest editors' draft for a new set of directives for the Content Security Policy header that specify heuristic protections for clickjacking and some other classes of UI redressing.  

It has been proposed that the "frame-ancestors" directive, which was dropped from CSP 1.0, should be revived as "embed-ancestors" as part of the set of UI Safety directives, and that it should obsolete X-Frame-Options, that is, user agents which understand UI Safety directives should ignore X-Frame-Options if any such directives are found.  For example, some web application authors may wish to allow embedding of resources if and only if the heuristic protections of the other UI Safety Directives are understood, and fall back to an X-Frame-Options "DENY" or "SAMEORIGIN" policy otherwise.


-Brad Hill