From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc7034.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 787 insertions(+)
 create mode 100644 doc/rfc/rfc7034.txt

(limited to 'doc/rfc/rfc7034.txt')

diff --git a/doc/rfc/rfc7034.txt b/doc/rfc/rfc7034.txt
new file mode 100644
index 0000000..9bc8157
--- /dev/null
+++ b/doc/rfc/rfc7034.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           D. Ross
+Request for Comments: 7034                                     Microsoft
+Category: Informational                                       T. Gondrom
+ISSN: 2070-1721                                           Thames Stanley
+                                                            October 2013
+
+
+                   HTTP Header Field X-Frame-Options
+
+Abstract
+
+   To improve the protection of web applications against clickjacking,
+   this document describes the X-Frame-Options HTTP header field, which
+   declares a policy, communicated from the server to the client
+   browser, regarding whether the browser may display the transmitted
+   content in frames that are part of other web pages.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7034.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Ross & Gondrom                Informational                     [Page 1]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
+   2.  X-Frame-Options Header . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Augmented Backus-Naur Form (ABNF)  . . . . . . . . . . . .  5
+       2.2.1.  Examples of X-Frame-Options  . . . . . . . . . . . . .  6
+     2.3.  Design Issues  . . . . . . . . . . . . . . . . . . . . . .  6
+       2.3.1.  Enable HTML Content from Other Domains . . . . . . . .  6
+       2.3.2.  Browser Behavior and Processing  . . . . . . . . . . .  6
+         2.3.2.1.  Violation of X-Frame-Options . . . . . . . . . . .  6
+         2.3.2.2.  Variation in Current Browser Behavior  . . . . . .  7
+         2.3.2.3.  Usage Design Pattern and Example Scenario for
+                   the ALLOW-FROM Parameter . . . . . . . . . . . . .  8
+         2.3.2.4.  No Caching of the X-Frame-Options Header . . . . .  8
+   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+     3.1.  Registration Template  . . . . . . . . . . . . . . . . . .  9
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+     4.1.  Privacy Considerations . . . . . . . . . . . . . . . . . . 10
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
+     5.2.  Informative References . . . . . . . . . . . . . . . . . . 11
+   Appendix A.  Browsers That Support X-Frame-Options . . . . . . . . 13
+   Appendix B.  Description of a Clickjacking Attack  . . . . . . . . 13
+     B.1.  Shop . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     B.2.  Online Shop Confirm Purchase Page  . . . . . . . . . . . . 13
+     B.3.  Flash Configuration  . . . . . . . . . . . . . . . . . . . 13
+   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ross & Gondrom                Informational                     [Page 2]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+1.  Introduction
+
+   In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options],
+   [CLICK-DEFENSE-BLOG], and [Mozilla-X-Frame-Options]) introduced the
+   use of a non-standard HTTP [RFC2616] header field "X-Frame-Options"
+   to protect against clickjacking [Clickjacking].  HTML-based web
+   applications can embed or "frame" other web pages.  Clickjacking is a
+   type of attack that occurs when an attacker uses multiple transparent
+   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
+   intending to click on the same place of the overlaying page from
+   server A.  Thus, the attacker is "hijacking" clicks meant for page A
+   and routing them to page B.  The attacker is tricking the user (who
+   sees the overlaying user interface content from page A) into clicking
+   specific locations on the underlying page 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.  In addition, server A may or may not be the attacker.
+
+   This specification provides informational documentation about the
+   current use and definition of the X-Frame-Options HTTP header field.
+   As described in Section 2.3.2.2, not all browsers implement
+   X-Frame-Options in exactly the same way, which can lead to unintended
+   results.  And, given that the "X-" construction is deprecated
+   [RFC6648], the X-Frame-Options header field will be replaced in the
+   future by the Frame-Options directive in the Content Security Policy
+   (CSP) version 1.1 [CSP-1-1].
+
+   A study [FRAME-BUSTING] demonstrated that existing anti-clickjacking
+   measures, e.g., frame-breaking JavaScript, have weaknesses that allow
+   their protection to be circumvented.
+
+   Short of configuring the browser to disable frames and scripts
+   entirely, which massively impairs browser utility, browser users are
+   vulnerable to this type of attack.
+
+   The use of "X-Frame-Options" allows a web page from host B to declare
+   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.,
+   from host A).  This is done by a policy declared in the HTTP header
+   and enforced by browser implementations as documented here.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+Ross & Gondrom                Informational                     [Page 3]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+2.  X-Frame-Options Header
+
+   The X-Frame-Options HTTP header field indicates a policy that
+   specifies whether the browser should render the transmitted resource
+   within a <frame> or an <iframe>.  Servers can declare this policy in
+   the header of their HTTP responses to prevent clickjacking attacks,
+   which ensures that their content is not embedded into other pages or
+   frames.
+
+2.1.  Syntax
+
+   The header field name is:
+
+      X-Frame-Options
+
+   There are three different values for the header field.  These values
+   are mutually exclusive; that is, the header field MUST be set to
+   exactly one of the three values.
+
+   DENY
+      A browser receiving content with this header field MUST NOT
+      display this content in any frame.
+
+   SAMEORIGIN
+      A browser receiving content with this header field MUST NOT
+      display this content in any frame from a page of different origin
+      than the content itself.
+
+      If a browser or plugin cannot reliably determine whether or not
+      the origin of the content and the frame are the same, this MUST be
+      treated as "DENY".
+
+      Please note that current implementations vary on the
+      interpretation of this criteria.  In some, it only allows a page
+      to be framed if the origin of the top-level browsing context is
+      identical to the origin of the content using the X-Frame-Options
+      directive; in others, it may consider the origin of the framing
+      page instead.  Also see 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.  In addition, refer to Section 4,
+      paragraph 2 for the resulting potential security problems.
+
+   ALLOW-FROM  (followed by a serialized-origin [RFC6454])
+      A browser receiving content with this header MUST NOT display this
+      content in a frame from any page with a top-level browsing context
+      of different origin than the specified origin.  While this can
+
+
+
+
+
+Ross & Gondrom                Informational                     [Page 4]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+      expose the page to risks by the trusted origin, in some cases, it
+      may be necessary to allow the framing by content from other
+      domains.
+
+   The meaning of the term "serialized-origin" is given in [RFC6454].
+   If the ALLOW-FROM value is used, it MUST be followed by a valid
+   origin [RFC6454] (as a subset of the URI [RFC3986]).
+
+   Any data beyond the domain address (i.e., any data after the "/"
+   separator) is to be ignored.  The algorithm to compare origins from
+   [RFC6454] SHOULD be used to verify that a referring page is of the
+   same origin as the content (in the case of SAMEORIGIN) or that the
+   referring page's origin is identical with the ALLOW-FROM serialized-
+   origin (in the case of ALLOW-FROM).  Though in conflict 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
+   statement are not permitted (see Section 2.3.2.3).
+
+2.2.   Augmented Backus-Naur Form (ABNF)
+
+   The RFC 5234 [RFC5234] ABNF of the X-Frame-Options header field value
+   is the following:
+
+         X-Frame-Options = "DENY"
+                   / "SAMEORIGIN"
+                   / ( "ALLOW-FROM" RWS SERIALIZED-ORIGIN )
+
+         RWS             = 1*( SP / HTAB )
+                       ; required whitespace
+
+   with serialized-origin as defined in [RFC6454] and required
+   whitespace (RWS) as defined in [HTTPbis-P1].
+
+   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 SP or transformed to all SP octets before
+   interpreting the field value or forwarding the message downstream.
+
+   SP and horizontal tab (HTAB) are as defined in Appendix B.1 of RFC
+   5234 [RFC5234].
+
+   The values are specified as ABNF strings; therefore, they are case-
+   insensitive.
+
+
+
+Ross & Gondrom                Informational                     [Page 5]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+2.2.1.  Examples of X-Frame-Options
+
+       X-Frame-Options: DENY
+
+       X-Frame-Options: SAMEORIGIN
+
+       X-Frame-Options: ALLOW-FROM https://example.com/
+
+2.3.  Design Issues
+
+2.3.1.  Enable HTML Content from Other Domains
+
+   There are a number of main direct vectors that enable HTML content
+   from other domains, and browser implementations of X-Frame-Options
+   cover all of them:
+
+   o  IFRAME tag
+
+   o  Frame tag
+
+   o  Object tag (requires a redirect)
+
+   o  Applet tag
+
+   o  Embed tag
+
+   Besides these, other ways to host HTML content can be possible.  For
+   example, some plugins may host HTML views directly.  If these plugins
+   appear essentially as frames (as opposed to top-level windows), the
+   plugins must conform to the X-Frame-Options policy as specified in
+   this document as well.
+
+2.3.2.  Browser Behavior and Processing
+
+   To allow secure implementations, browsers must behave in a consistent
+   and reliable way.
+
+   If an X-Frame-Options HTTP header field prohibits framing, the user
+   agent of the browser MAY immediately abort downloading or parsing of
+   the document.
+
+2.3.2.1.  Violation of 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
+   orders of the header, the browser SHOULD redirect to a "NOFRAME" page
+   as soon as possible.  For example, this can be a noframe.html page
+   that also states the full URL and hostname of the protected page.
+
+
+
+Ross & Gondrom                Informational                     [Page 6]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+   The NOFRAME page could provide the user with an option to open the
+   target URL in a new window.
+
+   Implementations of this vary: some browsers will show a message that
+   allows the user to safely open the target page in a new window,
+   whereas other implementations will simply render an empty frame.
+
+2.3.2.2.  Variation in Current Browser Behavior
+
+   There are currently variations in the implementation of the
+   X-Frame-Options header.  For example, not all browsers support the
+   "ALLOW-FROM" option.  "ALLOW-FROM" was initially an Internet Explorer
+   extension and, at the time of writing, has not been uniformly
+   implemented by other user agents.
+
+   Furthermore, the criteria for the SAMEORIGIN (and ALLOW-FROM)
+   directive may not be evaluated unanimously either: the known
+   implementations in Appendix A evaluate the SAMEORIGIN directive based
+   on the origin of the framed page and the top-level browsing context,
+   while other implementations might evaluate it based on the framed
+   page and the framing page, or the whole chain of nested frames in
+   between.
+
+   To illustrate the difference between the comparison of the "framing
+   page" and the "top-level browsing context", consider the following
+   scenario: web pages may embed frames with other pages that, 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 web page B in a frame, and web page B may contain
+   web page C in a frame.
+
+   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".
+
+
+
+Ross & Gondrom                Informational                     [Page 7]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+   These potential variations in the evaluation of the header by
+   different implementations impair the usage and reliability of this
+   HTTP header and have security implications as described in Section 4.
+   A revised version of X-Frame-Options in the form of a Frame-Options
+   directive in CSP 1.1 [CSP-1-1] will unify the behavior, and it is
+   expected 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
+          Parameter
+
+   As the "ALLOW-FROM" field only supports one serialized-origin, in
+   cases when the server wishes to allow more than one resource to frame
+   its content, the following design pattern can fulfill that need:
+
+   1.  A page that wants to render the requested content in a frame
+       supplies its own origin information to the server providing the
+       content to be framed via a query string parameter.
+
+   2.  The server verifies that the hostname meets its criteria, so that
+       the page is allowed to be framed by the target resource.  This
+       may, for example, happen via a lookup of a whitelist of trusted
+       domain names that are allowed to frame the page.  For example,
+       for a Facebook "Like" button, the server can check to see that
+       the supplied hostname matches the hostname(s) expected for that
+       "Like" button.
+
+   3.  The server returns the hostname in "X-Frame-Options: ALLOW-FROM"
+       if the proper criteria was met in step #2.
+
+   4.  The browser enforces the "X-Frame-Options: ALLOW-FROM" header.
+
+2.3.2.4.  No Caching of the X-Frame-Options Header
+
+   Caching the X-Frame-Options header for a resource is not recommended.
+   Caching the X-Frame-Options response could result in problems
+   because:
+
+   1.  For every http-request of the resource, the browser has to check
+       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.  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 web page 1 from domain A and web
+
+
+
+Ross & Gondrom                Informational                     [Page 8]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+       page 2 from domain B, and 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,
+       with the first pointing to origin A and the second pointing to
+       origin B.
+
+   However, we found that none of the major browsers listed in
+   Appendix A cache the responses.
+
+3.  IANA Considerations
+
+   IANA has included the specified HTTP header in the "Permanent Message
+   Header Field Name" registry as outlined in "Registration Procedures
+   for Message Header Fields" [RFC3864].
+
+3.1.  Registration Template
+
+   Permanent Message Header Field Names Template:
+
+   Header field name: X-Frame-Options
+
+   Applicable protocol: http [RFC2616]
+
+   Status: Informational
+
+   Author/change controller: IETF
+
+   Specification document(s): RFC 7034
+
+   Related information: None
+
+4.  Security Considerations
+
+   The introduction of the X-Frame-Options HTTP header field improves
+   the protection against clickjacking.  However, it is not self-
+   sufficient enough to protect against all kinds of these attack
+   vectors.  It must be used in conjunction with other security measures
+   like secure coding (e.g., input validation, output encoding, etc.)
+   and the Content Security Policy version 1.0 [CSP].
+
+   It is important to note that current implementations do not check the
+   origins of the framing resources' entire ancestor tree of frames, and
+   this may expose the resource to attack in multiple-nested scenarios.
+
+   The browser implementations evaluate based on the origin of the
+   framed page and the top-level browsing context (i.e., the most outer
+   frame):
+
+
+
+
+Ross & Gondrom                Informational                     [Page 9]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+   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
+   when 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
+   is explicitly ignored by user agents when declared with a meta
+   http-equiv tag.
+
+4.1.  Privacy Considerations
+
+   There are two kinds of potential data leakage to consider:
+
+   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 thus determine which other page is framing it.  This
+       is inherent by design, but it may lead to data-leakage or data-
+       protection concerns.
+
+   2.  The web server using the ALLOW-FROM directive effectively
+       discloses the origin specified in the header.  If a web server
+       wishes to reduce this leakage, it is recommended to generate the
+       ALLOW-FROM header for each request based on the design pattern as
+       described in Section 2.3.2.3.
+
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
+              December 2011.
+
+
+
+
+
+Ross & Gondrom                Informational                    [Page 10]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+5.2.  Informative References
+
+   [CLICK-DEFENSE-BLOG]
+              Lawrence, E., "IE8 Security Part VII: Clickjacking
+              Defenses", Microsoft Developer Network Blogs,
+              January 2009, <http://blogs.msdn.com/b/ie/archive/2009/01/
+              27/ie8-security-part-vii-clickjacking-defenses.aspx>.
+
+   [CSP]      Sterne, B. and A. Barth, "Content Security Policy 1.0",
+              W3C Candidate Recommendation CR-CSP-20121115,
+              November 2012,
+              <http://www.w3.org/TR/2012/CR-CSP-20121115/>.
+
+   [CSP-1-1]  Barth, A. and M. West, "Content Security Policy 1.1", W3C
+              Working Draft WD-CSP11-20130604, June 2013,
+              <http://www.w3.org/TR/2013/WD-CSP11-20130604/>.
+
+   [CSRF]     OWASP (Open Web Application Security Project), "Top-10
+              2013-A8-Cross-Site Request Forgery (CSRF)", June 2013,
+              <https://www.owasp.org/index.php/
+              Top_10_2013-A8-Cross-Site_Request_Forgery_%28CSRF%29>.
+
+   [Clickjacking]
+              OWASP (Open Web Application Security Project),
+              "Clickjacking", April 2013,
+              <http://www.owasp.org/index.php/Clickjacking>.
+
+   [FRAME-BUSTING]
+              Stanford Web Security Research, "Busting frame busting: a
+              study of clickjacking vulnerabilities at popular sites",
+              July 2010,
+              <http://seclab.stanford.edu/websec/framebusting/>.
+
+   [HTTPbis-P1]
+              Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
+              (HTTP/1.1): Message Syntax and Routing", Work in Progress,
+              September 2013.
+
+   [Microsoft-X-Frame-Options]
+              Lawrence, E., "Combating ClickJacking With X-Frame-
+              Options", Microsoft Developer Network Blogs, March 2010,
+              <http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/
+              combating-clickjacking-with-x-frame-options.aspx>.
+
+   [Mozilla-X-Frame-Options]
+              Mozilla Developer Network, "The X-Frame-Options response
+              header", August 2013, <https://developer.mozilla.org/
+              en-US/docs/The_X-FRAME-OPTIONS_response_header>.
+
+
+
+Ross & Gondrom                Informational                    [Page 11]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              September 2004.
+
+   [RFC6648]  Saint-Andre, P., Crocker, D., and M. Nottingham,
+              "Deprecating the "X-" Prefix and Similar Constructs in
+              Application Protocols", BCP 178, RFC 6648, June 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ross & Gondrom                Informational                    [Page 12]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+Appendix A.  Browsers That Support X-Frame-Options
+
+   o  Internet Explorer 8+
+
+   o  Firefox 3.6.9+
+
+   o  Opera 10.5+
+
+   o  Safari 4+
+
+   o  Chrome 4.1+
+
+Appendix B.  Description of a Clickjacking Attack
+
+   A more detailed explanation of clickjacking scenarios follows.
+
+B.1.  Shop
+
+   An Internet marketplace/shop offering a feature with a link/button to
+   "Buy this" gadget wants their affiliates (who could be malicious
+   attackers) to be able to stick the "Buy such and such from XYZ"
+   IFRAMES into their pages.  There is a possible clickjacking threat
+   here, which is why the marketplace/online shop needs to then
+   immediately navigate the main browsing context (or a new window) to a
+   confirmation page that is protected by anti-clickjacking protections.
+
+B.2.  Online Shop Confirm Purchase Page
+
+   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.
+   For that reason, the confirmation page uses a combination of
+   anti-CSRF (Cross Site Request Forgery [CSRF]) tokens and the
+   X-Frame-Options HTTP header field, mitigating clickjacking attacks.
+
+B.3.  Flash Configuration
+
+   Macromedia Flash configuration settings are set by a Flash object
+   that 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
+   clickjacking attack.  In order to prevent clickjacking attacks
+   against the security settings, the configuration page uses the
+   X-Frame-Options directive.
+
+Appendix C.  Acknowledgements
+
+   This document was derived from input from specifications published by
+   various browser vendors such as Microsoft (Eric Lawrence and David
+   Ross), Mozilla, Google, Opera, and Apple.
+
+
+
+Ross & Gondrom                Informational                    [Page 13]
+
+RFC 7034                     X-Frame-Options                October 2013
+
+
+Authors' Addresses
+
+   David Ross
+   Microsoft
+
+   EMail: dross@microsoft.com
+
+
+   Tobias Gondrom
+   Thames Stanley
+
+   EMail: tobias.gondrom@gondrom.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ross & Gondrom                Informational                    [Page 14]
+
-- 
cgit v1.2.3