idnits 2.17.1
draft-ietf-websec-x-frame-options-12.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (August 27, 2013) is 3887 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p1-messaging-23
-- Obsolete informational reference (is this intentional?): RFC 2616
(Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 WEBSEC D. Ross
3 Internet-Draft Microsoft
4 Intended status: Informational T. Gondrom
5 Expires: February 28, 2014 Thames Stanley
6 August 27, 2013
8 HTTP Header Field X-Frame-Options
9 draft-ietf-websec-x-frame-options-12
11 Abstract
13 To improve the protection of web applications against Clickjacking,
14 this definition describes the X-Frame-Options HTTP response header
15 field that declares a policy communicated from the server to the
16 client browser on whether the browser may display the transmitted
17 content in frames that are part of other web pages. This
18 informational document serves to document the existing use and
19 specification of this X-Frame-Options HTTP response header field.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on February 28, 2014.
38 Copyright Notice
40 Copyright (c) 2013 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
57 2. X-Frame-Options Header . . . . . . . . . . . . . . . . . . . 3
58 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2.2. Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . 5
60 2.2.1. Examples of X-Frame-Options . . . . . . . . . . . . . 5
61 2.3. Design Issues . . . . . . . . . . . . . . . . . . . . . . 5
62 2.3.1. Enable HTML content from other domains . . . . . . . 6
63 2.3.2. Browser Behaviour and Processing . . . . . . . . . . 6
64 2.3.2.1. Violation of X-Frame-Options . . . . . . . . . . 6
65 2.3.2.2. Variation in current browser behaviour . . . . . 6
66 2.3.2.3. Usage design pattern and example scenario for the
67 ALLOW-FROM parameter . . . . . . . . . . . . . . 8
68 2.3.2.4. No caching of the X-Frame-Options header . . . . 8
69 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
71 4.1. Registration Template . . . . . . . . . . . . . . . . . . 9
72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
73 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10
74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
75 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
76 6.2. Informative References . . . . . . . . . . . . . . . . . 11
77 Appendix A. Browsers that support X-Frame-Options . . . . . . . 12
78 Appendix B. Description of a Clickjacking attack . . . . . . . . 12
79 B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . 12
80 B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 12
81 B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 13
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
84 1. Introduction
86 In 2009 and 2010 many browser vendors ([Microsoft-X-Frame-Options],
87 [CLICK-DEFENSE-BLOG], [Mozilla-X-Frame-Options]) introduced the use
88 of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to
89 protect against Clickjacking [Clickjacking]. HTML-based web
90 applications can embed or "frame" other web pages. Clickjacking is a
91 type of attack that occurs when an attacker uses multiple transparent
92 or opaque layers in the user interface to trick a user into clicking
93 on a button or link on another page from server B when they were
94 intending to click on the same place of the overlaying page from
95 server A. Thus, the attacker is "hijacking" clicks meant for their
96 page A and routing them to another page B. The attacker is tricking
97 the user (who sees the overlaying user interface content from page A)
98 into clicking specific locations on the underlying page from server
99 B, triggering some actions on server B and potentially using an
100 existing session context in that step. This is an attack on both the
101 user and on server B. And server A may or may not be the attacker.
103 This specification provides informational documentation about the
104 current use and definition of the X-Frame-Options HTTP header field.
105 As described in Section 2.3.2.2 not all browsers implement X-Frame-
106 Options exactly in the sames way, which can lead to unintended
107 results. And given that the "X-" construction is deprecated
108 [RFC6648], the X-Frame-Options header field will in the future be
109 replaced by the Frame-Options directive in the Content Security
110 Policy Version 1.1 [CSP-1-1].
112 Existing anti-ClickJacking measures, e.g. Frame-breaking Javascript,
113 have weaknesses so that their protection can be circumvented as a
114 study [FRAME-BUSTING] demonstrated.
116 Short of configuring the browser to disable frames and script
117 entirely, which massively impairs browser utility, browser users are
118 vulnerable to this type of attack.
120 "X-Frame-Options" allows a web page from host B to declare that its
121 content (for example a button, links, text, etc.) must not be
122 displayed in a frame ( or