draft-ietf-websec-x-frame-options-08.txt   draft-ietf-websec-x-frame-options-09.txt 
WEBSEC D. Ross WEBSEC D. Ross
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Informational T. Gondrom Intended status: Informational T. Gondrom
Expires: February 12, 2014 Thames Stanley Expires: February 14, 2014 Thames Stanley
August 11, 2013 August 13, 2013
HTTP Header Field X-Frame-Options HTTP Header Field X-Frame-Options
draft-ietf-websec-x-frame-options-08 draft-ietf-websec-x-frame-options-09
Abstract Abstract
To improve the protection of web applications against Clickjacking, To improve the protection of web applications against Clickjacking,
this definition describes the X-Frame-Options HTTP response header this definition describes the X-Frame-Options HTTP response header
field that declares a policy communicated from the server to the field that declares a policy communicated from the server to the
client browser on whether the browser may display the transmitted client browser on whether the browser may display the transmitted
content in frames that are part of other web pages. This content in frames that are part of other web pages. This
informational document serves to document the existing use and informational document serves to document the existing use and
specification of this X-Frame-Options HTTP response header field. specification of this X-Frame-Options HTTP response header field.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2014. This Internet-Draft will expire on February 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. X-Frame-Options Header . . . . . . . . . . . . . . . . . . . 3 2. X-Frame-Options Header . . . . . . . . . . . . . . . . . . . 3
2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . 4 2.2. Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . 5
2.2.1. Examples of X-Frame-Options . . . . . . . . . . . . . 5 2.2.1. Examples of X-Frame-Options . . . . . . . . . . . . . 5
2.3. Design Issues . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Design Issues . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Enable HTML content from other domains . . . . . . . 5 2.3.1. Enable HTML content from other domains . . . . . . . 5
2.3.2. Browser Behaviour and Processing . . . . . . . . . . 6 2.3.2. Browser Behaviour and Processing . . . . . . . . . . 6
2.3.2.1. Violation of X-Frame-Options . . . . . . . . . . 6 2.3.2.1. Violation of X-Frame-Options . . . . . . . . . . 6
2.3.2.2. Variation in current browser behaviour . . . . . 6 2.3.2.2. Variation in current browser behaviour . . . . . 6
2.3.2.3. Usage design pattern and example scenario for the 2.3.2.3. Usage design pattern and example scenario for the
ALLOW-FROM parameter . . . . . . . . . . . . . . 7 ALLOW-FROM parameter . . . . . . . . . . . . . . 7
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. Registration Template . . . . . . . . . . . . . . . . . . 7 4.1. Registration Template . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Privacy Considreations . . . . . . . . . . . . . . . . . 8 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Browsers that support X-Frame-Options . . . . . . . 10 Appendix A. Browsers that support X-Frame-Options . . . . . . . 10
Appendix B. Description of a Clickjacking attack . . . . . . . . 10 Appendix B. Description of a Clickjacking attack . . . . . . . . 11
B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 11 B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 11
B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 11 B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 11
B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 11 B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In 2009 and 2010 many browser vendors ([Microsoft-X-Frame-Options], In 2009 and 2010 many browser vendors ([Microsoft-X-Frame-Options],
[CLICK-DEFENSE-BLOG], [Mozilla-X-Frame-Options]) introduced the use [CLICK-DEFENSE-BLOG], [Mozilla-X-Frame-Options]) introduced the use
of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to
skipping to change at page 3, line 11 skipping to change at page 3, line 11
server A. Thus, the attacker is "hijacking" clicks meant for their server A. Thus, the attacker is "hijacking" clicks meant for their
page A and routing them to another page B. The attacker is tricking page A and routing them to another page B. The attacker is tricking
the user (who sees the overlaying user interface content from page A) the user (who sees the overlaying user interface content from page A)
into clicking specific locations on the underlying page from server into clicking specific locations on the underlying page from server
B, triggering some actions on server B and potentially using an B, triggering some actions on server B and potentially using an
existing session context in that step. This is an attack on both the existing session context in that step. This is an attack on both the
user and on server B. And server A may or may not be the attacker. user and on server B. And server A may or may not be the attacker.
This specification provides informational documentation about the This specification provides informational documentation about the
current use and definition of the X-Frame-Options HTTP header field. current use and definition of the X-Frame-Options HTTP header field.
Given that the "X-" construction is deprecated [RFC6648], the X As described in Section 2.3.2.2 not all browsers implement X-Frame-
-Frame-Options header field will in the future be replaced by the Options exactly in the sames way, which can lead to unintended
Frame-Options directive in the Content Security Policy Version 1.1 results. And given that the "X-" construction is deprecated
[CSP-1-1]. [RFC6648], the X-Frame-Options header field will in the future be
replaced by the Frame-Options directive in the Content Security
Policy Version 1.1 [CSP-1-1].
Existing anti-ClickJacking measures, e.g. Frame-breaking Javascript, Existing anti-ClickJacking measures, e.g. Frame-breaking Javascript,
have weaknesses so that their protection can be circumvented as a have weaknesses so that their protection can be circumvented as a
study [FRAME-BUSTING] demonstrated. study [FRAME-BUSTING] demonstrated.
Short of configuring the browser to disable frames and script Short of configuring the browser to disable frames and script
entirely, which massively impairs browser utility, browser users are entirely, which massively impairs browser utility, browser users are
vulnerable to this type of attack. vulnerable to this type of attack.
"X-Frame-Options" allows a secure web page from host B to declare "X-Frame-Options" allows a secure web page from host B to declare
that its content (for example a button, links, text, etc.) must not that its content (for example a button, links, text, etc.) must not
be displayed in a frame (<frame> or <iframe>) of another page (e.g. be displayed in a frame (<frame> or <iframe>) of another page (e.g.
from host A). This is done by a policy declared in the HTTP header from host A). This is done by a policy declared in the HTTP header
and enforced by browser implementations as documented here. and enforced by browser implementations as documented here.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 4, line 35 skipping to change at page 4, line 41
ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin) ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin)
A browser receiving content with this header MUST NOT display A browser receiving content with this header MUST NOT display
this content in a frame from any page with a top-level browsing this content in a frame from any page with a top-level browsing
context of different origin than the specified origin. While context of different origin than the specified origin. While
this can expose the page to risks by the trusted origin, in this can expose the page to risks by the trusted origin, in
some cases it may be necessary to allow the framing by content some cases it may be necessary to allow the framing by content
from other domains. from other domains.
If the ALLOW-FROM value is used, it MUST be followed by a valid URI. If the ALLOW-FROM value is used, it MUST be followed by a valid URI.
Any data beyond the domain address (i.e. any data after the "/" Any data beyond the domain address (i.e. any data after the "/"
separator) is to be ignored. And the algorithm to compare origins separator) is to be ignored. And the algorithm to compare origins
from [RFC6454] SHOULD be used to verify that a referring page is of from [RFC6454] SHOULD be used to verify that a referring page is of
the same origin as the content or that the referring page's origin is the same origin as the content or that the referring page's origin is
identical with the ALLOW-FROM URI. Though in conflict with identical with the ALLOW-FROM URI. Though in conflict with
[RFC6454], current implementations do not consider the port as a [RFC6454], current implementations do not consider the port as a
defining component of the origin. defining component of the origin.
Wildcards or lists to declare multiple domains in one ALLOW-FROM Wildcards or lists to declare multiple domains in one ALLOW-FROM
statement are not permitted (see Section 2.3.2.3). statement are not permitted (see Section 2.3.2.3).
skipping to change at page 7, line 7 skipping to change at page 7, line 13
either: one implementation may evaluate the SAMEORIGIN option based either: one implementation may evaluate the SAMEORIGIN option based
on the origin of the framed page and the framing page, while another on the origin of the framed page and the framing page, while another
may evaluate based on the framed page and the top-level browsing- may evaluate based on the framed page and the top-level browsing-
context. context.
These variations in the evaluation of the header by different These variations in the evaluation of the header by different
implementations impair the useage and reliability of this http implementations impair the useage and reliability of this http
header. A revised version of x-frame-options in the form of a frame- header. A revised version of x-frame-options in the form of a frame-
options directive in the CSP 1.1[CSP-1-1] will unify the behaviour options directive in the CSP 1.1[CSP-1-1] will unify the behaviour
and it is expected that newer implementations will use it rather than and it is expected that newer implementations will use it rather than
the mechanisms documented here" the mechanisms documented here.
2.3.2.3. Usage design pattern and example scenario for the ALLOW-FROM 2.3.2.3. Usage design pattern and example scenario for the ALLOW-FROM
parameter parameter
As the "ALLOW-FROM" field only supports one URI, in cases when the As the "ALLOW-FROM" field only supports one URI, in cases when the
server wishes to allow more than one resource to frame its content, server wishes to allow more than one resource to frame its content,
the following design pattern can fulfil that need: the following design pattern can fulfil that need:
1. A page that wants to render the requested content in a frame 1. A page that wants to render the requested content in a frame
supplies its own origin information to the server providing the supplies its own origin information to the server providing the
skipping to change at page 8, line 20 skipping to change at page 8, line 29
Related information: Related information:
Figure 1 Figure 1
5. Security Considerations 5. Security Considerations
The introduction of the X-FRAME-OPTIONS http header field does The introduction of the X-FRAME-OPTIONS http header field does
improve the protection against Clickjacking. However, it is not improve the protection against Clickjacking. However, it is not
self-sufficient on its own to protect against all kinds of these self-sufficient on its own to protect against all kinds of these
attack vectors. It must be used in conjunction with other security attack vectors. It must be used in conjunction with other security
measures like secure coding (e.g. input validation, output encoding, measures like secure coding (e.g. input validation, output encoding,
...) and the Content Security Policy [CSP]. ...) and the Content Security Policy [CSP].
It is important to note that current implementations do not check the It is important to note that current implementations do not check the
origins of the entire ancestor tree of frames of the framing origins of the entire ancestor tree of frames of the framing
resources, and this may expose the resource to attack in multiple- resources, and this may expose the resource to attack in multiple-
nested scenarios. For example, if a resource on origin A embeds nested scenarios. For example, if a resource on origin A embeds
untrusted content from origin B, that untrusted content can embed untrusted content from origin B, that untrusted content can embed
another resource from origin A with an X-Frame-Options: SAMEORIGIN another resource from origin A with an X-Frame-Options: SAMEORIGIN
policy and that check would pass if the user agent only verifies the policy and that check would pass if the user agent only verifies the
top-level browsing context. Therefore web developers should be aware top-level browsing context. Therefore web developers should be aware
that embedding content from other sites can leave their web pages that embedding content from other sites can leave their web pages
vulnerable to clickjacking even if the X-Frame-Options header is vulnerable to clickjacking even if the X-Frame-Options header is
used. used.
Furthermore, X-Frame-Options must be sent as an HTTP header field and Furthermore, X-Frame-Options must be sent as an HTTP header field and
is explicitly ignored by user agents when declared with a meta http- is explicitly ignored by user agents when declared with a meta http-
equiv tag. equiv tag.
5.1. Privacy Considreations 5.1. Privacy Considerations
The parameter ALLOW-FROM allows a page to guess who is framing it. The parameter ALLOW-FROM allows a page to guess who is framing it.
This is inherent by design, but may lead to data leakage or data This is inherent by design, but may lead to data leakage or data
protection concerns. protection concerns.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 11, line 19 skipping to change at page 11, line 23
The marketplace wants their affiliates (who could be malicious The marketplace wants their affiliates (who could be malicious
attackers) to be able to stick the "Buy such-and-such from XYZ" attackers) to be able to stick the "Buy such-and-such from XYZ"
IFRAMES into their pages. There is a possible Clickjacking threat IFRAMES into their pages. There is a possible Clickjacking threat
here, which is why the marketplace/onlineshop needs to then here, which is why the marketplace/onlineshop needs to then
immediately navigate the main browsing context (or a new window) to a immediately navigate the main browsing context (or a new window) to a
confirmation page which is protected by anti-Clickjacking confirmation page which is protected by anti-Clickjacking
protections. protections.
B.2. Online Shop Confirm Purchase Page B.2. Online Shop Confirm Purchase Page
The "Confirm Purchase"" page of an online shop must be shown to the The "Confirm Purchase" page of an online shop must be shown to the
end user without the risk of an overlay or misuse by an attacker. end user without the risk of an overlay or misuse by an attacker.
For that reason, the confirmation page uses a combination of anti- For that reason, the confirmation page uses a combination of anti-
CSRF (Cross Site Request Forgery, [CSRF]) tokens and the X-FRAME- CSRF (Cross Site Request Forgery, [CSRF]) tokens and the X-FRAME-
OPTIONS HTTP header field, mitigating ClickJacking attacks. OPTIONS HTTP header field, mitigating ClickJacking attacks.
B.3. Flash Configuration B.3. Flash Configuration
Macromedia Flash configuration settings are set by a Flash object Macromedia Flash configuration settings are set by a Flash object
which can run only from a specific configuration page on Macromedia's which can run only from a specific configuration page on Macromedia's
site. The object runs inside the page and thus can be subject to a site. The object runs inside the page and thus can be subject to a
 End of changes. 15 change blocks. 
20 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/