draft-ietf-websec-x-frame-options-10.txt   draft-ietf-websec-x-frame-options-11.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 19, 2014 Thames Stanley Expires: February 28, 2014 Thames Stanley
August 18, 2013 August 27, 2013
HTTP Header Field X-Frame-Options HTTP Header Field X-Frame-Options
draft-ietf-websec-x-frame-options-10 draft-ietf-websec-x-frame-options-11
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 19, 2014. This Internet-Draft will expire on February 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . 6 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 . . . . . . . . . . . . . . 8 ALLOW-FROM parameter . . . . . . . . . . . . . . 8
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2.4. No caching of the X-Frame-Options header . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Registration Template . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4.1. Registration Template . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Browsers that support X-Frame-Options . . . . . . . 12 Appendix A. Browsers that support X-Frame-Options . . . . . . . 12
Appendix B. Description of a Clickjacking attack . . . . . . . . 12 Appendix B. Description of a Clickjacking attack . . . . . . . . 12
B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 12 B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 12
B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 12 B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 12
B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 12 B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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
skipping to change at page 7, line 10 skipping to change at page 7, line 10
allows the user to safely open the target page in a new window. allows the user to safely open the target page in a new window.
Other implementations will simply render an empty frame. Other implementations will simply render an empty frame.
2.3.2.2. Variation in current browser behaviour 2.3.2.2. Variation in current browser behaviour
There are currently variations in the implementation of the X-FRAME- There are currently variations in the implementation of the X-FRAME-
OPTIONS header. For example not all browsers support the "ALLOW- OPTIONS header. For example not all browsers support the "ALLOW-
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 Furthermore the criteria for the SAMEORIGIN (and ALLOW-FROM)
either: one implementation may evaluate the SAMEORIGIN option based directive may not be evaluated unanimously either: The known
on the origin of the framed page and the framing page, while another implementations in Appendix A evaluate the SAMEORIGIN directive based
may evaluate based on the framed page and the top-level browsing- on the origin of the framed page and the top-level browsing-context,
context. while other implementations might evaluate based on the framed page
and the framing page, or the whole chain of nested frames inbetween.
To illustrate the difference between the comparison with "framing To illustrate the difference between the comparison with "framing
page" and the "top-level browsing-context" consider the following page" and the "top-level browsing-context" consider the following
scenario: Web pages may embed frames with other pages which in turn 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 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 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 A may contain in a frame web page B, and web page B contains in a
frame web page C. frame web page C.
Web page A Web page A
skipping to change at page 7, line 42 skipping to change at page 7, line 43
.... ....
<frame src="https://URI_of_web_page_C" /> <frame src="https://URI_of_web_page_C" />
</html> </html>
And so forth... And so forth...
In this example, for the nested frames with the inner framed web page 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- C, the most outer web page A would be the "top-level browsing-
context" and web page B would be the "framing page" context" and web page B would be the "framing page"
These variations in the evaluation of the header by different These potential variations in the evaluation of the header by
implementations impair the useage and reliability of this http header different implementations impair the useage and reliability of this
and have security implications as described in section 5. A revised http header and have security implications as described in section 5.
version of x-frame-options in the form of a frame-options directive A revised version of x-frame-options in the form of a frame-options
in the CSP 1.1[CSP-1-1] will unify the behaviour and it is expected directive in the CSP 1.1[CSP-1-1] will unify the behaviour and it is
that newer implementations will use it rather than the mechanisms expected that newer implementations will use it rather than the
documented here. 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 serialized-origin, in As the "ALLOW-FROM" field only supports one serialized-origin, in
cases when the server wishes to allow more than one resource to frame cases when the server wishes to allow more than one resource to frame
its content, 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
skipping to change at page 8, line 29 skipping to change at page 8, line 29
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
the supplied hostname matches the hostname(s) expected for that the supplied hostname matches the hostname(s) expected for that
"Like" button. "Like" button.
3. The server returns the hostname in X-FRAME-OPTIONS: ALLOW-FROM if 3. The server returns the hostname in X-FRAME-OPTIONS: ALLOW-FROM if
the proper criteria was met in step #2. the proper criteria was met in step #2.
4. The browser enforces the X-FRAME-OPTIONS: ALLOW-FROM header. 4. The browser enforces the X-FRAME-OPTIONS: ALLOW-FROM header.
2.3.2.4. No caching of the X-Frame-Options header
It is not recommended to cache the X-Frame-Options header for a
resource. Caching the X-Frame-Options response could result in
problems because:
1. The browser has to check for every http-request of the resource
whether the X-Frame-Options header has been set and then act
accordingly, as a resource itself might be created dynamically
and the header could change with it, too.
2. And also, as outlined in section 2.3.2.3., servers may generate X
-Frame-Options header responses depending on the request.
Example case: Considering that we have only one serialized-origin
in the ALLOW-FROM directive, imagine a user has multiple pages
open in his browser tabs with one of web page 1 from domain A and
the second of web page 2 from domain B, both frame the same page
from domain C with the ALLOW-FROM directive. In that case the
page needs to reply to both requests with different X-Frame-
Options headers, the first pointing to origin A, the second to
origin B.
However, we found that none of the major browsers listed in
Appendix A cache the responses.
3. Acknowledgements 3. Acknowledgements
This document was derived from input from specifications published by This document was derived from input from specifications published by
various browser vendors such as Microsoft (Eric Lawrence, David various browser vendors such as Microsoft (Eric Lawrence, David
Ross), Mozilla, Google, Opera and Apple. Ross), Mozilla, Google, Opera and Apple.
4. IANA Considerations 4. IANA Considerations
This memo is a request to IANA to include the specified HTTP header This memo is a request to IANA to include the specified HTTP header
in the registry as outlined in Registration Procedures for Message in the registry as outlined in Registration Procedures for Message
skipping to change at page 9, line 24 skipping to change at page 9, line 49
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. nested scenarios.
Depending on the implementation, different security problems may The browser implementations evaluate based on the origin of the
arise: framed page and the top-level browsing-context (i.e. most outer
frame):
a. If the browser implementation evaluates based on the origins of
the framed page and the framing page:
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 If a resource from origin A embeds untrusted content from origin B,
the framed page and the top-level browsing-context (i.e. most that untrusted content can embed another resource from origin A with
outer frame): an X-Frame-Options: SAMEORIGIN policy and that check would pass when
If a resource from origin A embeds untrusted content from origin the user agent only verifies the top-level browsing context.
B, that untrusted content can embed another resource from origin Therefore web developers should be aware that embedding content from
A with an X-Frame-Options: SAMEORIGIN policy and that check would other sites can leave their web pages vulnerable to clickjacking even
pass if the user agent only verifies the top-level browsing if the X-Frame-Options header is used.
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
There are two kinds of potential data leakage to consider: There are two kinds of potential data leakage to consider:
1. Using X-FRAME-OPTIONS with the parameter ALLOW-FROM allows a page 1. Using X-FRAME-OPTIONS with the parameter ALLOW-FROM allows a page
 End of changes. 12 change blocks. 
48 lines changed or deleted 59 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/