[websec] WGLC feedback for X-Frame-Options
Julian Reschke <julian.reschke@gmx.de> Tue, 06 November 2012 17:25 UTC
Return-Path: <julian.reschke@gmx.de>
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 77FA521F8A60 for <websec@ietfa.amsl.com>; Tue, 6 Nov 2012 09:25:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level:
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qou+WGQvY1WE for <websec@ietfa.amsl.com>; Tue, 6 Nov 2012 09:25:49 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BCD7721F8A49 for <websec@ietf.org>; Tue, 6 Nov 2012 09:25:47 -0800 (PST)
Received: (qmail invoked by alias); 06 Nov 2012 17:25:46 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp040) with SMTP; 06 Nov 2012 18:25:46 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18JOXI1QToJafd2c7L+TVDwrYpZMl+fAbXO3J0McF fCcAeGCBV3eRgr
Message-ID: <50994817.1030503@gmx.de>
Date: Tue, 06 Nov 2012 18:25:43 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <D418C856-1FA9-4FA3-805D-6A44042B5A36@checkpoint.com>
In-Reply-To: <D418C856-1FA9-4FA3-805D-6A44042B5A36@checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: IETF WebSec WG <websec@ietf.org>
Subject: [websec] WGLC feedback for X-Frame-Options
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: Tue, 06 Nov 2012 17:25:50 -0000
Hi there, here's my feedback from the HTTP/editorial point of view: > Abstract > > To improve the protection of web applications against Clickjacking > this standard defines an http response header that declares a policy s/standard/specification/ s/http response header/HTTP response header field/ > communicated from a host to the client browser on whether the browser > must not display the transmitted content in frames of other web > pages. This drafts serves to document the existing use and drafts? > In 2009 and 2010 many browser vendors ([Microsoft-X-Frame-Options], > [CLICK-DEFENSE-BLOG], [Mozilla-X-Frame-Options]) introduced the use > of a non-standard http header RFC 2616 [RFC2616] "X-Frame-Options" to s/http header RFC 2616 [RFC2616]/HTTP [RFC2616] header field/ > protect against Clickjacking [Clickjacking]. This draft is to > document the current use of X-Frame-Options header and shall in the > future be replaced by the Frame-Options [FRAME-OPTIONS] standard. What's supposed to be replaced is the header field, not the spec, right? > 2. X-Frame-Options Header > > > The X-Frame-Options HTTP response header indicates a policy whether a s/header/header field/ throughout. > browser MUST NOT allow to render a page in a <frame> or <iframe> . whitespace... > 2.1. Syntax > > > The header field name is: > X-Frame-Options > > There are three different values for the header field. These values > are exclusive, that is NOT more than one of the three values MUST be > set. maybe "exactly one"? > DENY > A browser receiving content with this header MUST NOT display > this content in any frame. > > SAMEORIGIN > A browser receiving content with this header MUST NOT display > this content in any frame from a page of different origin than > the content itself. Reference ORIGIN spec? > ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin) > A browser receiving content with this header MUST NOT display > this content in a frame from any page with a top-level browsing > contex of different origin than the specified origin. While > this can expose the page to risks by the trusted origin, in > some cases it may be necessary to allow the framing by content > from other domains. > For example: X-FRAME-OPTIONS: ALLOW-FROM: > https://www.domain.com/ The example needs reformatting. > The ALLOW-FROM URI MUST be valid. > Any data beyond the domain address (i.e. any data after the "/" > separator) is to be ignored. And the algorithm to compare origins authority component? > from [RFC6454] SHOULD be used to verify a referring page is of the > same origin as the content or that the referring page's origin is > identical with the ALLOW-FROM URI. > > Wildcards or lists to declare multiple domains in one ALLOW-FROM > statement are not permitted. > > Please note that in conflict with [RFC6454], current implementations > do not consider the port as a defining component of the origin. > > 2.2. Backus-Naur Form (BNF) > > > The RFC 822 [RFC0822] EBNF of the X-Frame-Options header is: > > X-Frame-Options = "Frame-Options" ":" "DENY"/ "SAMEORIGIN" / > ("ALLOW-FROM" ":" URI) That should reference HTTPbis P1, and just define the field *value, such as: X-Frame-Options = "DENY" / "SAMEORIGIN" / ( "ALLOW-FROM" OWS ":" OWS URI ) OWS = <HTTPbis P1 ref> URI = <RFC3986 ref> Note that this makes the keywords case-insensitive; if this is intended it might make sense to call it out. Otherwise, the ABNF needs to be fixed. > 6.1. Normative References > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. I'm pretty sure you need normative references for HTTP, ABNF and URI. > ... Best regards, Julian
- [websec] WGLC for X-Frame-Options Yoav Nir
- Re: [websec] WGLC for X-Frame-Options Yoav Nir
- Re: [websec] WGLC for X-Frame-Options Alexey Melnikov
- Re: [websec] WGLC for X-Frame-Options Julian Reschke
- [websec] WGLC feedback for X-Frame-Options Julian Reschke
- Re: [websec] WGLC for X-Frame-Options Hill, Brad
- Re: [websec] WGLC for X-Frame-Options Yoav Nir
- Re: [websec] WGLC for X-Frame-Options Peter Saint-Andre
- Re: [websec] WGLC feedback for X-Frame-Options Julian Reschke
- Re: [websec] WGLC feedback for X-Frame-Options Yoav Nir