draft-ietf-websec-x-frame-options-05.txt   draft-ietf-websec-x-frame-options-06.txt 
WEBSEC D. Ross WEBSEC D. Ross
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Informational T. Gondrom Intended status: Informational T. Gondrom
Expires: January 16, 2014 Thames Stanley Expires: January 28, 2014 Thames Stanley
July 15, 2013 July 27, 2013
HTTP Header Field X-Frame-Options HTTP Header Field X-Frame-Options
draft-ietf-websec-x-frame-options-05 draft-ietf-websec-x-frame-options-06
Abstract Abstract
To improve the protection of web applications against Clickjacking, To improve the protection of web applications against Clickjacking,
this specification describes the X-Frame-Options HTTP response header this specification 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 January 16, 2014. This Internet-Draft will expire on January 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . 4 2.2. Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . 4
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 . . . . . . . . . . 5 2.3.2. Browser Behaviour and Processing . . . . . . . . . . 6
2.3.2.1. Violation of X-Frame-Options . . . . . . . . . . 5 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 . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Privacy Considreations . . . . . . . . . . . . . . . . . 8 5.1. Privacy Considreations . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . 10
B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 10 B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 10
B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 10 B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 10
B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 10 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
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
on a button or link on another page from server B when they were on a button or link on another page from server B when they were
intending to click on the same place of the overlaying page from intending to click on the same place of the overlaying page from
server A. Thus, the attacker is "hijacking" clicks meant for their server A. Thus, Thus, the attacker is "hijacking" clicks meant for
page A and routing them to another page B, possibly belonging to their page A and routing them to another page B. The attacker is
another domain and thereby triggering actions on the second server B tricking the user (who sees the overlaying user interface content
without the knowledge nor intention of the user and potentially using from page A) into clicking specific locations on the underlying page
an existing session context and login in that step. from server B, triggering some actions on server B and potentially
using an 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.
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 Given that the "X-" construction is deprecated [RFC6648], the X
-Frame-Options header field will in the future be replaced by the -Frame-Options header field will in the future be replaced by the
Frame-Options directive in the Content Security Policy Version 1.1 Frame-Options directive in the Content Security Policy Version 1.1
[CSP-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
skipping to change at page 4, line 17 skipping to change at page 4, line 20
this content in any frame. this content in any frame.
SAMEORIGIN SAMEORIGIN
A browser receiving content with this header field MUST NOT A browser receiving content with this header field MUST NOT
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 to be interpretation of this criteria: In some it only allows a page
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 compare to the origin of OPTIONS directive; in others it may consider the origin of the
the framing page. framing page instead.
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. 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: is:
X-Frame-Options = "DENY" X-Frame-Options = "DENY"
/ "SAMEORIGIN" / "SAMEORIGIN"
/ ( "ALLOW-FROM" RWS URI ) / ( "ALLOW-FROM" RWS URI )
With URI as defined in [RFC3986] and RWS and OWS as defined in With URI as defined in [RFC3986] and the definition of RWS (required
[HTTPbis-P1]. The values are specified as ABNF strings, and whitespace) is the same as in [HTTPbis-P1].
therefore are case-insensitive.
RWS is used when at least one linear whitespace octet is required to
separate field tokens. RWS SHOULD be generated as a single space
(SP). Multiple RWS octets that occur within field-content SHOULD
either be replaced with a single SP or transformed to all SP octets
before interpreting the field value or forwarding the message
downstream.
The values are specified as ABNF strings, and therefore are case-
insensitive.
2.2.1. Examples of X-Frame-Options 2.2.1. Examples of X-Frame-Options
X-FRAME-OPTIONS: DENY X-FRAME-OPTIONS: DENY
X-FRAME-OPTIONS: SAMEORIGIN X-FRAME-OPTIONS: SAMEORIGIN
X-FRAME-OPTIONS: ALLOW-FROM https://example.com/ X-FRAME-OPTIONS: ALLOW-FROM https://example.com/
2.3. Design Issues 2.3. Design Issues
skipping to change at page 6, line 4 skipping to change at page 6, line 20
2.3.2. Browser Behaviour and Processing 2.3.2. Browser Behaviour and Processing
To allow secure implementations, browsers must behave in a consistent To allow secure implementations, browsers must behave in a consistent
and reliable way. and reliable way.
If an X-Frame-Options HTTP header field prohibits framing, the user- If an X-Frame-Options HTTP header field prohibits framing, the user-
agent of the browser MAY immediately abort downloading or parsing of agent of the browser MAY immediately abort downloading or parsing of
the document. the document.
2.3.2.1. Violation of X-Frame-Options 2.3.2.1. Violation of X-Frame-Options
When a browser discovers that loaded content with the X-FRAME-OPTIONS When a browser discovers that loaded content with the X-FRAME-OPTIONS
header field would be displayed in a frame against the specified header field would be displayed in a frame against the specified
orders of the header, the browser SHOULD redirect as soon as possible orders of the header, the browser SHOULD redirect as soon as possible
to a "No-Frame" page. to a "No-Frame" page. For example this can be a noframe.html page
that also states the full URL and hostname of the protected page.
"No-Frame" Page
If the display of content is denied by the X-FRAME-OPTIONS header an
error page SHOULD be displayed. For example this can be a
noframe.html page also stating the full URL of the protected page and
the hostname of the protected page.
The NoFrame page MAY provide the user with an option to open the The NoFrame page could provide the user with an option to open the
target URL in a new window. target URL in a new window.
Implementations of this vary, some browsers will show a message that Implementations of this vary, some browsers will show a message that
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 IE (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.
And the criteria for the SAMEORIGIN option is not evaluated The criteria for the SAMEORIGIN option is not evaluated unanimously
unanimously either: one implementation may evaluate the SAMEORIGIN either: one implementation may evaluate the SAMEORIGIN option based
option based on the origin of the framed page and the framing page, on the origin of the framed page and the framing page, while another
while another may evaluate based on the framed page and the top-level may evaluate based on the framed page and the top-level browsing-
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] shall unify the behaviour options directive in the CSP 1.1[CSP-1-1] will unify the behaviour
and replace this document in the future. and replace this document in the future.
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 does support only one URI, in cases when As the "ALLOW-FROM" field does support only one URI, in cases when
the server wishes to allow more than one resource to frame its the server wishes to allow more than one resource to frame its
content, the following design pattern is recommended: content, the following design pattern is recommended:
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
skipping to change at page 7, line 21 skipping to change at page 7, line 38
"Like" button. "Like" button.
3. The server return the hostname in X-FRAME-OPTIONS: ALLOW-FROM if 3. The server return 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.
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 like Microsoft (Eric Lawrence, David Ross), various browser vendors such as Microsoft (Eric Lawrence, David
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
Header Fields [RFC3864] Header Fields [RFC3864]
4.1. Registration Template 4.1. Registration Template
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE: PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:
skipping to change at page 7, line 35 skipping to change at page 8, line 4
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
Header Fields [RFC3864] Header Fields [RFC3864]
4.1. Registration Template 4.1. Registration Template
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE: PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:
Header field name: X-Frame-Option Header field name: X-Frame-Option
Applicable protocol: http [RFC2616] Applicable protocol: http [RFC2616]
Status: Standard Status: informational
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): draft-ietf-websec-x-frame-options Specification document(s): draft-ietf-websec-x-frame-options
Related information: Related information:
Figure 1 Figure 1
5. Security Considerations 5. Security Considerations
skipping to change at page 8, line 36 skipping to change at page 8, line 47
5.1. Privacy Considreations 5.1. Privacy Considreations
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
[HTTPbis-P1]
IETF, "Hypertext Transfer Protocol (HTTP/1.1): Message
Syntax and Routing", 2013, <http://tools.ietf.org/html/
draft-ietf-httpbis-p1-messaging-22>.
[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
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 9, line 34 skipping to change at page 9, line 44
[Clickjacking] [Clickjacking]
OWASP (Open Web Application Security Project), OWASP (Open Web Application Security Project),
"Clickjacking", 2010, "Clickjacking", 2010,
<http://www.owasp.org/index.php/Clickjacking>. <http://www.owasp.org/index.php/Clickjacking>.
[FRAME-BUSTING] [FRAME-BUSTING]
Stanford Web Security Research, "Busting frame busting: a Stanford Web Security Research, "Busting frame busting: a
study of clickjacking vulnerabilities at popular sites", study of clickjacking vulnerabilities at popular sites",
2010, <http://seclab.stanford.edu/websec/framebusting/>. 2010, <http://seclab.stanford.edu/websec/framebusting/>.
[HTTPbis-P1]
IETF, "Hypertext Transfer Protocol (HTTP/1.1): Message
Syntax and Routing", 2013, <http://tools.ietf.org/html/
draft-ietf-httpbis-p1-messaging-22>.
[Microsoft-X-Frame-Options] [Microsoft-X-Frame-Options]
Microsoft, "Combating ClickJacking With X-Frame-Options", Microsoft, "Combating ClickJacking With X-Frame-Options",
2010, <http://blogs.msdn.com/b/ieinternals/archive/2010/03 2010, <http://blogs.msdn.com/b/ieinternals/archive/2010/03
/30/combating-clickjacking-with-x-frame-options.aspx>. /30/combating-clickjacking-with-x-frame-options.aspx>.
[Mozilla-X-Frame-Options] [Mozilla-X-Frame-Options]
Mozilla, "The X-Frame-Options response header", 2010, Mozilla, "The X-Frame-Options response header", 2010,
<https://developer.mozilla.org/en-US/docs/The_X-FRAME- <https://developer.mozilla.org/en-US/docs/The_X-FRAME-
OPTIONS_response_header>. OPTIONS_response_header>.
 End of changes. 22 change blocks. 
45 lines changed or deleted 52 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/