draft-ietf-websec-x-frame-options-09.txt   draft-ietf-websec-x-frame-options-10.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 14, 2014 Thames Stanley Expires: February 19, 2014 Thames Stanley
August 13, 2013 August 18, 2013
HTTP Header Field X-Frame-Options HTTP Header Field X-Frame-Options
draft-ietf-websec-x-frame-options-09 draft-ietf-websec-x-frame-options-10
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 14, 2014. This Internet-Draft will expire on February 19, 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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . 5 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 . . . . . . . 6
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 . . . . . . . . . . . . . . 8
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. Registration Template . . . . . . . . . . . . . . . . . . 8 4.1. Registration Template . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 9 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Browsers that support X-Frame-Options . . . . . . . 10 Appendix A. Browsers that support X-Frame-Options . . . . . . . 12
Appendix B. Description of a Clickjacking attack . . . . . . . . 11 Appendix B. Description of a Clickjacking attack . . . . . . . . 12
B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 11 B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 12
B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 11 B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 12
B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 11 B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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
protect against Clickjacking [Clickjacking]. HTML-based web protect against Clickjacking [Clickjacking]. HTML-based web
applications can embed or "frame" other web pages. Clickjacking is a applications can embed or "frame" other web pages. Clickjacking is a
type of attack that occurs when an attacker uses multiple transparent type of attack that occurs when an attacker uses multiple transparent
or opaque layers in the user interface to trick a user into clicking or opaque layers in the user interface to trick a user into clicking
skipping to change at page 3, line 26 skipping to change at page 3, line 26
Policy Version 1.1 [CSP-1-1]. 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 web page from host B to declare that its
that its content (for example a button, links, text, etc.) must not content (for example a button, links, text, etc.) must not be
be displayed in a frame (<frame> or <iframe>) of another page (e.g. displayed in a frame (<frame> or <iframe>) of another page (e.g. from
from host A). This is done by a policy declared in the HTTP header host A). This is done by a policy declared in the HTTP header and
and enforced by browser implementations as documented here. 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].
2. X-Frame-Options Header 2. X-Frame-Options Header
The X-Frame-Options HTTP response header field indicates a policy on The X-Frame-Options HTTP response header field indicates a policy on
skipping to change at page 4, line 30 skipping to change at page 4, line 30
display this content in any frame from a page of different display this content in any frame from a page of different
origin than the content itself. origin than the content itself.
If a browser or plugin can not reliably determine whether the If a browser or plugin can not reliably determine whether the
origin of the content and the frame have the same origin, this origin of the content and the frame have the same origin, this
MUST be treated as "DENY". MUST be treated as "DENY".
Please note that current implementations vary on the Please note that current implementations vary on the
interpretation of this criteria: In some it only allows a page interpretation of this criteria: In some it only allows a page
to be framed if the origin of the top-level browsing-context is to be framed if the origin of the top-level browsing-context is
identical to the origin of the content using the X-FRAME- identical to the origin of the content using the X-FRAME-
OPTIONS directive; in others it may consider the origin of the OPTIONS directive; in others it may consider the origin of the
framing page instead. framing page instead. See also section 2.3.2.2 for more
details on the nesting of frames and variations in the handling
of this header field by different browsers. And refer to
section 5 paragraph 2 for the resulting potential security
problems.
ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin) ALLOW-FROM (followed by a serialized-origin [RFC6454])
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. The meaning of the term "serialized-origin" is given in [RFC6454].
Any data beyond the domain address (i.e. any data after the "/" If the ALLOW-FROM value is used, it MUST be followed by a valid
origin [RFC6454] (as a subset of URI [RFC3986])
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 (in the case of SAMEORIGIN) or that
identical with the ALLOW-FROM URI. Though in conflict with the referring page's origin is identical with the ALLOW-FROM
[RFC6454], current implementations do not consider the port as a serialized-origin (in the case of ALLOW-FROM). Though in conflict
defining component of the origin. with [RFC6454], current implementations do not consider the port as a
defining component of the origin. I.e. existing implementations
differ with [RFC6454] in that origins with the same protocol but
different port values are considered equivalent.
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).
2.2. Augmented Backus-Naur Form (ABNF) 2.2. Augmented Backus-Naur Form (ABNF)
The RFC 5234 [RFC5234] ABNF of the X-Frame-Options header field value The RFC 5234 [RFC5234] ABNF of the X-Frame-Options header field value
is the following. is the following.
X-Frame-Options = "DENY" X-Frame-Options = "DENY"
/ "SAMEORIGIN" / "SAMEORIGIN"
/ ( "ALLOW-FROM" RWS URI ) / ( "ALLOW-FROM" RWS SERIALIZED-ORIGIN )
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
; required whitespace ; required whitespace
With URI as defined in [RFC3986] and the definition of RWS (required With serialized-origin as defined in [RFC6454] and the definition of
whitespace) is the same as in [HTTPbis-P1]. RWS (required whitespace) is the same as in [HTTPbis-P1].
RWS is used when at least one linear whitespace octet is required to RWS is used when at least one linear whitespace octet is required to
separate field tokens. RWS SHOULD be generated as a single space separate field tokens. RWS SHOULD be generated as a single space
(SP). Multiple RWS octets that occur within field-content SHOULD (SP). Multiple RWS octets that occur within field-content SHOULD
either be replaced with a single SP or transformed to all SP octets either be replaced with a single SP or transformed to all SP octets
before interpreting the field value or forwarding the message before interpreting the field value or forwarding the message
downstream. downstream.
And SP (space) and HTAB (horizontal tab) are as defined in RFC 5234 And SP (space) and HTAB (horizontal tab) are as defined in RFC 5234
[RFC5234], Appendix B.1. [RFC5234], Appendix B.1.
skipping to change at page 7, line 8 skipping to change at page 7, line 16
FROM" option. "ALLOW-FROM" was initially an Internet Explorer FROM" option. "ALLOW-FROM" was initially an Internet Explorer
extension and at the time of writing has not been uniformly extension and at the time of writing has not been uniformly
implemented by other user agents. implemented by other user agents.
The criteria for the SAMEORIGIN option is not evaluated unanimously The criteria for the SAMEORIGIN option is not evaluated unanimously
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.
To illustrate the difference between the comparison with "framing
page" and the "top-level browsing-context" consider the following
scenario: Web pages may embed frames with other pages which in turn
embed frames with other pages as well and so on. In theory this can
result in an infinite nesting of framed pages. For example web page
A may contain in a frame web page B, and web page B contains in a
frame web page C.
Web page A
<html>
....
<frame src="https://URI_of_web_page_B" />
</html>
Web Page B
<html>
....
<frame src="https://URI_of_web_page_C" />
</html>
And so forth...
In this example, for the nested frames with the inner framed web page
C, the most outer web page A would be the "top-level browsing-
context" and web page B would be the "framing page"
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
header. A revised version of x-frame-options in the form of a frame- and have security implications as described in section 5. A revised
options directive in the CSP 1.1[CSP-1-1] will unify the behaviour version of x-frame-options in the form of a frame-options directive
and it is expected that newer implementations will use it rather than in the CSP 1.1[CSP-1-1] will unify the behaviour and it is expected
the mechanisms documented here. that newer implementations will use it rather than 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 serialized-origin, in
server wishes to allow more than one resource to frame its content, cases when the server wishes to allow more than one resource to frame
the following design pattern can fulfil that need: its content, 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
to-be-framed content via a querystring parameter. to-be-framed content via a querystring parameter.
2. The Server verifies the hostname meets its criteria so that the 2. The Server verifies the hostname meets its criteria so that the
page can be allowed to be framed by the target resource. This page can be allowed to be framed by the target resource. This
may for example happen via a look-up of a white-list of trusted may for example happen via a look-up of a white-list of trusted
domain names that are allowed to frame the page. For example, domain names that are allowed to frame the page. For example,
for a Facebook "Like" button, the server can check to see that for a Facebook "Like" button, the server can check to see that
skipping to change at page 8, line 29 skipping to change at page 9, line 16
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.
untrusted content from origin B, that untrusted content can embed
another resource from origin A with an X-Frame-Options: SAMEORIGIN Depending on the implementation, different security problems may
policy and that check would pass if the user agent only verifies the arise:
top-level browsing context. Therefore web developers should be aware
that embedding content from other sites can leave their web pages a. If the browser implementation evaluates based on the origins of
vulnerable to clickjacking even if the X-Frame-Options header is the framed page and the framing page:
used. Suppose a web page A (from origin 1) embeds a web page B (from
origin 2) in a frame or iframe which in turn embeds web page C
(from origin 2) using the x-frame-options header in a frame. In
this case web page B needs to use X-Frame-Options as well, or
else a malicious page A could frame page B and with that
indirectly also page C. Therefore web developers should make
sure that all pages from an origin that is allowed to frame a
given resource web page C should also use X-Frame-Options or
otherwise risk exposing web page C indirectly to Clickjacking
attacks. And so forth recursively until the top-level browsing-
context (i.e. most outer frame) is reached.
b. If the browser implementation evaluates based on the origin of
the framed page and the top-level browsing-context (i.e. most
outer frame):
If a resource from origin A embeds untrusted content from origin
B, that untrusted content can embed another resource from origin
A with an X-Frame-Options: SAMEORIGIN policy and that check would
pass if the user agent only verifies the top-level browsing
context. Therefore web developers should be aware that embedding
content from other sites can leave their web pages vulnerable to
clickjacking even if the X-Frame-Options header is 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 Considerations 5.1. Privacy Considerations
The parameter ALLOW-FROM allows a page to guess who is framing it. There are two kinds of potential data leakage to consider:
This is inherent by design, but may lead to data leakage or data
protection concerns. 1. Using X-FRAME-OPTIONS with the parameter ALLOW-FROM allows a page
to guess or infer information about who is framing it. A web
server may answer requests with the X-FRAME-OPTIONS ALLOW-FROM
header and by thus determine which other page is framing it.
This is inherent by design, but may lead to data leakage or data
protection concerns.
2. The web server using the ALLOW-FROM directive may disclose to
other parties who request the page in the header by which page it
is allowed to be framed. If a web server wishes to reduce this
leakage, it is recommended to generate the ALLOW-FRAM header for
each request based on the design pattern as described in section
2.3.2.3.
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
 End of changes. 19 change blocks. 
55 lines changed or deleted 124 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/