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 (<frame> or <iframe>) of another page (e.g. from
123	   host A).  This is done by a policy declared in the HTTP header and
124	   enforced by browser implementations as documented here.

126	1.1.  Requirements Language

128	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
129	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
130	   document are to be interpreted as described in RFC 2119 [RFC2119].

132	2.  X-Frame-Options Header

134	   The X-Frame-Options HTTP response header field indicates a policy on
135	   whether the browser should render the transmitted resource within a
136	   <frame> or <iframe>.  Servers can declare this policy in the header
137	   of their HTTP responses to prevent clickjacking attacks, and by this
138	   ensuring that their content is not embedded into other pages or
139	   frames.

141	2.1.  Syntax

143	   The header field name is:
144	   X-Frame-Options
145	   There are three different values for the header field.  These values
146	   are mutually exclusive, that is exactly one of the three values MUST
147	   be set.

149	   DENY
150	         A browser receiving content with this header MUST NOT display
151	         this content in any frame.

153	   SAMEORIGIN
154	         A browser receiving content with this header field MUST NOT
155	         display this content in any frame from a page of different
156	         origin than the content itself.
157	         If a browser or plugin can not reliably determine whether the
158	         origin of the content and the frame have the same origin, this
159	         MUST be treated as "DENY".
160	         Please note that current implementations vary on the
161	         interpretation of this criteria: In some it only allows a page
162	         to be framed if the origin of the top-level browsing-context is
163	         identical to the origin of the content using the X-FRAME-
164	         OPTIONS directive; in others it may consider the origin of the
165	         framing page instead.  See also section 2.3.2.2 for more
166	         details on the nesting of frames and variations in the handling
167	         of this header field by different browsers.  And refer to
168	         section 5 paragraph 2 for the resulting potential security
169	         problems.

171	   ALLOW-FROM  (followed by a serialized-origin [RFC6454])
172	         A browser receiving content with this header MUST NOT display
173	         this content in a frame from any page with a top-level browsing
174	         context of different origin than the specified origin.  While
175	         this can expose the page to risks by the trusted origin, in
176	         some cases it may be necessary to allow the framing by content
177	         from other domains.

179	   The meaning of the term "serialized-origin" is given in [RFC6454].
180	   If the ALLOW-FROM value is used, it MUST be followed by a valid
181	   origin [RFC6454] (as a subset of URI [RFC3986])
182	   Any data beyond the domain address (i.e. any data after the "/"
183	   separator) is to be ignored.  And the algorithm to compare origins
184	   from [RFC6454] SHOULD be used to verify that a referring page is of
185	   the same origin as the content (in the case of SAMEORIGIN) or that
186	   the referring page's origin is identical with the ALLOW-FROM
187	   serialized-origin (in the case of ALLOW-FROM).  Though in conflict
188	   with [RFC6454], current implementations do not consider the port as a
189	   defining component of the origin.  I.e. existing implementations
190	   differ with [RFC6454] in that origins with the same protocol but
191	   different port values are considered equivalent.

193	   Wildcards or lists to declare multiple domains in one ALLOW-FROM
194	   statement are not permitted (see Section 2.3.2.3).

196	2.2.  Augmented Backus-Naur Form (ABNF)

198	   The RFC 5234 [RFC5234] ABNF of the X-Frame-Options header field value
199	   is the following.

201	         X-Frame-Options = "DENY"
202	                   / "SAMEORIGIN"
203	                   / ( "ALLOW-FROM" RWS SERIALIZED-ORIGIN )

205	         RWS             = 1*( SP / HTAB )
206	                       ; required whitespace

208	   With serialized-origin as defined in [RFC6454] and the definition of
209	   RWS (required whitespace) is the same as in [HTTPbis-P1].

211	   RWS is used when at least one linear whitespace octet is required to
212	   separate field tokens.  RWS SHOULD be generated as a single space
213	   (SP).  Multiple RWS octets that occur within field-content SHOULD
214	   either be replaced with a single SP or transformed to all SP octets
215	   before interpreting the field value or forwarding the message
216	   downstream.

218	   And SP (space) and HTAB (horizontal tab) are as defined in RFC 5234
219	   [RFC5234], Appendix B.1.

221	   The values are specified as ABNF strings, and therefore are case-
222	   insensitive.

224	2.2.1.  Examples of X-Frame-Options

226	       X-FRAME-OPTIONS: DENY

228	       X-FRAME-OPTIONS: SAMEORIGIN

230	       X-FRAME-OPTIONS: ALLOW-FROM https://example.com/

232	2.3.  Design Issues
233	2.3.1.  Enable HTML content from other domains

235	   There are a number of main direct vectors that enable HTML content
236	   from other domains and browser implementations of X-Frame-Options
237	   cover all of them:

239	   o  IFRAME tag

241	   o  Frame tag

243	   o  The Object tag (requires a redirect)

245	   o  Applet tag

247	   o  Embed tag

249	   Besides these, other ways to host HTML content can be possible.  For
250	   example some plugins may host HTML views directly.  If these plugins
251	   appear essentially as frames (as opposed to top-level windows), the
252	   plugins must conform to the X-FRAME-OPTIONS policy as specified in
253	   this document as well.

255	2.3.2.  Browser Behaviour and Processing

257	   To allow secure implementations, browsers must behave in a consistent
258	   and reliable way.

260	   If an X-Frame-Options HTTP header field prohibits framing, the user-
261	   agent of the browser MAY immediately abort downloading or parsing of
262	   the document.

264	2.3.2.1.  Violation of X-Frame-Options

266	   When a browser discovers that loaded content with the X-FRAME-OPTIONS
267	   header field would be displayed in a frame against the specified
268	   orders of the header, the browser SHOULD redirect as soon as possible
269	   to a "No-Frame" page.  For example this can be a noframe.html page
270	   that also states the full URL and hostname of the protected page.

272	   The NoFrame page could provide the user with an option to open the
273	   target URL in a new window.

275	   Implementations of this vary, some browsers will show a message that
276	   allows the user to safely open the target page in a new window.
277	   Other implementations will simply render an empty frame.

279	2.3.2.2.  Variation in current browser behaviour
280	   There are currently variations in the implementation of the X-FRAME-
281	   OPTIONS header.  For example not all browsers support the "ALLOW-
282	   FROM" option.  "ALLOW-FROM" was initially an Internet Explorer
283	   extension and at the time of writing has not been uniformly
284	   implemented by other user agents.

286	   Furthermore the criteria for the SAMEORIGIN (and ALLOW-FROM)
287	   directive may not be evaluated unanimously either: The known
288	   implementations in Appendix A evaluate the SAMEORIGIN directive based
289	   on the origin of the framed page and the top-level browsing-context,
290	   while other implementations might evaluate based on the framed page
291	   and the framing page, or the whole chain of nested frames inbetween.

293	   To illustrate the difference between the comparison with "framing
294	   page" and the "top-level browsing-context" consider the following
295	   scenario: Web pages may embed frames with other pages which in turn
296	   embed frames with other pages as well and so on.  In theory this can
297	   result in an infinite nesting of framed pages.  For example web page
298	   A may contain in a frame web page B, and web page B contains in a
299	   frame web page C.

301	   Web page A
302	   <html>
303	   ....
304	   <frame src="https://URI_of_web_page_B" />
305	   </html>

307	   Web Page B
308	   <html>
309	   ....
310	   <frame src="https://URI_of_web_page_C" />
311	   </html>

313	   And so forth...

315	   In this example, for the nested frames with the inner framed web page
316	   C, the most outer web page A would be the "top-level browsing-
317	   context" and web page B would be the "framing page"

319	   These potential variations in the evaluation of the header by
320	   different implementations impair the useage and reliability of this
321	   http header and have security implications as described in section 5.
322	   A revised version of x-frame-options in the form of a frame-options
323	   directive in the CSP 1.1[CSP-1-1] will unify the behaviour and it is
324	   expected that newer implementations will use it rather than the
325	   mechanisms documented here.

327	2.3.2.3.  Usage design pattern and example scenario for the ALLOW-FROM
328	          parameter

330	   As the "ALLOW-FROM" field only supports one serialized-origin, in
331	   cases when the server wishes to allow more than one resource to frame
332	   its content, the following design pattern can fulfil that need:

334	   1.  A page that wants to render the requested content in a frame
335	       supplies its own origin information to the server providing the
336	       to-be-framed content via a querystring parameter.

338	   2.  The Server verifies the hostname meets its criteria so that the
339	       page can be allowed to be framed by the target resource.  This
340	       may for example happen via a look-up of a white-list of trusted
341	       domain names that are allowed to frame the page.  For example,
342	       for a Facebook "Like" button, the server can check to see that
343	       the supplied hostname matches the hostname(s) expected for that
344	       "Like" button.

346	   3.  The server returns the hostname in X-FRAME-OPTIONS: ALLOW-FROM if
347	       the proper criteria was met in step #2.

349	   4.  The browser enforces the X-FRAME-OPTIONS: ALLOW-FROM header.

351	2.3.2.4.  No caching of the X-Frame-Options header

353	   It is not recommended to cache the X-Frame-Options header for a
354	   resource.  Caching the X-Frame-Options response could result in
355	   problems because:

357	   1.  The browser has to check for every http-request of the resource
358	       whether the X-Frame-Options header has been set and then act
359	       accordingly, as a resource itself might be created dynamically
360	       and the header could change with it, too.

362	   2.  And also, as outlined in section 2.3.2.3., servers may generate X
363	       -Frame-Options header responses depending on the request.
364	       Example case: Considering that we have only one serialized-origin
365	       in the ALLOW-FROM directive, imagine a user has multiple pages
366	       open in his browser tabs with one of web page 1 from domain A and
367	       the second of web page 2 from domain B, both frame the same page
368	       from domain C with the ALLOW-FROM directive.  In that case the
369	       page needs to reply to both requests with different X-Frame-
370	       Options headers, the first pointing to origin A, the second to
371	       origin B.

373	   However, we found that none of the major browsers listed in
374	   Appendix A cache the responses.

376	3.  Acknowledgements

378	   This document was derived from input from specifications published by
379	   various browser vendors such as Microsoft (Eric Lawrence, David
380	   Ross), Mozilla, Google, Opera and Apple.

382	4.  IANA Considerations

384	   This memo is a request to IANA to include the specified HTTP header
385	   in the registry as outlined in Registration Procedures for Message
386	   Header Fields [RFC3864]

388	4.1.  Registration Template

390	   PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:

392	   Header field name: X-Frame-Options

394	   Applicable protocol: http [RFC2616]

396	   Status: informational

398	   Author/Change controller: IETF

400	   Specification document(s): draft-ietf-websec-x-frame-options

402	   Related information:

404	                                 Figure 1

406	5.  Security Considerations

408	   The introduction of the X-FRAME-OPTIONS http header field does
409	   improve the protection against Clickjacking.  However, it is not
410	   self-sufficient on its own to protect against all kinds of these
411	   attack vectors.  It must be used in conjunction with other security
412	   measures like secure coding (e.g. input validation, output encoding,
413	   ...) and the Content Security Policy [CSP].

415	   It is important to note that current implementations do not check the
416	   origins of the entire ancestor tree of frames of the framing
417	   resources, and this may expose the resource to attack in multiple-
418	   nested scenarios.

420	   The browser implementations evaluate based on the origin of the
421	   framed page and the top-level browsing-context (i.e. most outer
422	   frame):

424	   If a resource from origin A embeds untrusted content from origin B,
425	   that untrusted content can embed another resource from origin A with
426	   an X-Frame-Options: SAMEORIGIN policy and that check would pass when
427	   the user agent only verifies the top-level browsing context.
428	   Therefore web developers should be aware that embedding content from
429	   other sites can leave their web pages vulnerable to clickjacking even
430	   if the X-Frame-Options header is used.

432	   Furthermore, X-Frame-Options must be sent as an HTTP header field and
433	   is explicitly ignored by user agents when declared with a meta http-
434	   equiv tag.

436	5.1.  Privacy Considerations

438	   There are two kinds of potential data leakage to consider:

440	   1.  Using X-FRAME-OPTIONS with the parameter ALLOW-FROM allows a page
441	       to guess or infer information about who is framing it.  A web
442	       server may answer requests with the X-FRAME-OPTIONS ALLOW-FROM
443	       header and by thus determine which other page is framing it.
444	       This is inherent by design, but may lead to data leakage or data
445	       protection concerns.

447	   2.  The web server using the ALLOW-FROM directive may disclose to
448	       other parties who request the page in the header by which page it
449	       is allowed to be framed.  If a web server wishes to reduce this
450	       leakage, it is recommended to generate the ALLOW-FROM header for
451	       each request based on the design pattern as described in section
452	       2.3.2.3.

454	6.  References

456	6.1.  Normative References

458	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
459	              Requirement Levels", BCP 14, RFC 2119, March 1997.

461	   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
462	              Resource Identifier (URI): Generic Syntax", STD 66, RFC
463	              3986, January 2005.

465	   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
466	              Specifications: ABNF", STD 68, RFC 5234, January 2008.

468	   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, December
469	              2011.

471	6.2.  Informative References

473	   [CLICK-DEFENSE-BLOG]
474	              Microsoft, "Clickjacking Defense", 2009, <http://
475	              blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-
476	              vii-clickjacking-defenses.aspx>.

478	   [CSP-1-1]  Barth, A. and M. West, "Content Security Policy 1.1", W3C
479	              Working Draft WD-CSP11-20130604, June 2013,
480	              <http://www.w3.org/TR/2013/WD-CSP11-20130604/>.

482	              Latest version available at

484	   [CSP]      Sterne, B. and A. Barth, "Content Security Policy 1.0",
485	              W3C Candidate Recommendation CR-CSP-20121115, November
486	              2012, <http://www.w3.org/TR/2012/CR-CSP-20121115/>.

488	              Latest version available at

490	   [CSRF]     OWASP (Open Web Application Security Project), "OWASP
491	              Top-10: Cross-Site Request Forgery (CSRF)", 2010, <https:/
492	              /www.owasp.org/index.php/Top_10_2013-A8-Cross-
493	              Site_Request_Forgery_%28CSRF%29>.

495	   [Clickjacking]
496	              OWASP (Open Web Application Security Project),
497	              "Clickjacking", 2010,
498	              <http://www.owasp.org/index.php/Clickjacking>.

500	   [FRAME-BUSTING]
501	              Stanford Web Security Research, "Busting frame busting: a
502	              study of clickjacking vulnerabilities at popular sites",
503	              2010, <http://seclab.stanford.edu/websec/framebusting/>.

505	   [HTTPbis-P1]
506	              IETF, "Hypertext Transfer Protocol (HTTP/1.1): Message
507	              Syntax and Routing", 2013, <http://tools.ietf.org/html/
508	              draft-ietf-httpbis-p1-messaging-23>.

510	   [Microsoft-X-Frame-Options]
511	              Microsoft, "Combating ClickJacking With X-Frame-Options",
512	              2010, <http://blogs.msdn.com/b/ieinternals/archive/2010/03
513	              /30/combating-clickjacking-with-x-frame-options.aspx>.

515	   [Mozilla-X-Frame-Options]
516	              Mozilla, "The X-Frame-Options response header", 2010,
517	              <https://developer.mozilla.org/en-US/docs/The_X-FRAME-
518	              OPTIONS_response_header>.

520	   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
521	              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
522	              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

524	   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
525	              Procedures for Message Header Fields", BCP 90, RFC 3864,
526	              September 2004.

528	   [RFC6648]  Saint-Andre, P., Crocker, D., and M. Nottingham,
529	              "Deprecating the "X-" Prefix and Similar Constructs in
530	              Application Protocols", BCP 178, RFC 6648, June 2012.

532	Appendix A.  Browsers that support X-Frame-Options

534	   o  Internet Explorer 8+

536	   o  Firefox 3.6.9+

538	   o  Opera 10.5+

540	   o  Safari 4+

542	   o  Chrome 4.1+

544	Appendix B.  Description of a Clickjacking attack

546	   More detailed explanation of Clickjacking scenarios

548	B.1.  Shop

550	   An Internet Marketplace/Shop offering a feature with a link/button to
551	   "Buy this" Gadget
552	   The marketplace wants their affiliates (who could be malicious
553	   attackers) to be able to stick the "Buy such-and-such from XYZ"
554	   IFRAMES into their pages.  There is a possible Clickjacking threat
555	   here, which is why the marketplace/onlineshop needs to then
556	   immediately navigate the main browsing context (or a new window) to a
557	   confirmation page which is protected by anti-Clickjacking
558	   protections.

560	B.2.  Online Shop Confirm Purchase Page

562	   The "Confirm Purchase" page of an online shop must be shown to the
563	   end user without the risk of an overlay or misuse by an attacker.
564	   For that reason, the confirmation page uses a combination of anti-
565	   CSRF (Cross Site Request Forgery, [CSRF]) tokens and the X-FRAME-
566	   OPTIONS HTTP header field, mitigating ClickJacking attacks.

568	B.3.  Flash Configuration

570	   Macromedia Flash configuration settings are set by a Flash object
571	   which can run only from a specific configuration page on Macromedia's
572	   site.  The object runs inside the page and thus can be subject to a
573	   ClickJacking attack.  In order to prevent ClickJacking attacks
574	   against the security settings, the configuration page uses the X
575	   -FRAME-OPTIONS directive.

577	Authors' Addresses

579	   David Ross
580	   Microsoft
581	   U.S.

583	   Tobias Gondrom
584	   Thames Stanley
585	   Kruegerstr. 5A
586	   Unterschleissheim
587	   Germany

589	   Phone: +44 7521003005
590	   Email: tobias.gondrom@gondrom.org