HTTP Header Field X-Frame-Options
draft-ietf-websec-x-frame-options-12

[Ballot discuss]
(D1) The privacy considerations make no sense to me.  To whom is data being leaked?  To the browser?  To random people who send a request to a URI?  Do you mean that X-Frame-Options leaks information about who the site authorizes?  That's true, but also true of things like CORS.  If this is the concern, you should recommend a mitigation that's basically the same as what CORS does, namely varying the value of X-Frame-Options based on the Referer or Origin header.

(D2) It seems like this is a value that browsers might cache, to avoid unnecessary requests if the same page is framed in the future.  If this is something browsers do today, please say so. 

(D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI?  In other words, what does it mean to send "X-Frame-Options: ALLOW-FROM https://example.com/this/is/a/path?query#fragment"?

[Ballot discuss]
(D1) The privacy considerations make no sense to me.  To whom is data being leaked?  To the browser?  To random people who send a request to a URI?  Do you mean that X-Frame-Options leaks information about who the site authorizes?  That's true, but also true of things like CORS.  If this is the concern, you should recommend a mitigation that's basically the same as what CORS does, namely varying the value of X-Frame-Options based on the Referer or Origin header.

(D2) It seems like this is a value that browsers might cache, to avoid unnecessary requests if the same page is framed in the future.  If this is something browsers do today, please say so. 

(D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI?  In other words, what does it mean to send "X-Frame-Options: ALLOW-FROM https://example.com/this/is/a/path?query#fragment"? 

(D3) In the ALLOW-FROM: what does "top level context" mean?  Do you really mean the top level here, as opposed to the next one up?  For example, suppose A loads B in an iframe, and B loads C, and then C sends an X-Frame-Options header with ALLOW-FROM.  Is the ALLOW-FROM origin compared to B or A?  In either case, you should also note the attacks that remain.  For example, if the answer is B, then B needs to use X-Frame-Options as well, or else, A can maliciously frame A within B.  Or if the answer is A, then C is trusting A not to load any malicious intermediate frames B.

[Ballot comment]
(C1) In the Introduction, the phrase "secure web page" would seem to imply that this mechanism only applies to pages delivered over HTTPS, which I'm pretty sure isn't true.  Suggest just deleting "secure".

(C2) In Section 2.1, the sentence starting "And the algorithm" seems to imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I think you actually mean something like:
"""
And 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 URI (in the case of ALLOW-FROM).
"""

[Ballot comment]

(Personal opinion only, no change requested unless it
resonates with folks.) I would prefer that this not say
that NoScript impairs broswer utility. I find it fine.

Other than that, this is a fine draft, thanks.

[Ballot comment]
The introduction of the concept of origins in 2.1 is a bit clumsy—the term is used under the SAMEORIGIN heading without being defined, and is later defined as a constraint specific only to ALLOW-FROM.  Text about browser implementations for SAMEORIGIN and ALLOW-FROM is repeated here and in later sections.  It would be better to simply refer to the later section.  If I were to clean up this section, I would do something like the following:

DENY
        A browser receiving content with this header 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 can not reliably determine whether the
        origin of the content and the frame have the same origin, this
        MUST be treated as "DENY".  Section 2.3.2.2 documents
        variations in the handling of this header field by different
        browsers.

  ALLOW-FROM  (followed by a URI [RFC3986] of a trusted origin)
        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 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 "origin" is given in [RFC6454].
  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 "/"
  separator) is to be ignored.  And the algorithm to compare origins
  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
  identical with the ALLOW-FROM URI.  Though in conflict with
  [RFC6454], current implementations do not consider the port as a
  defining component of the origin.

I also noticed that in another exchange about this document, someone said that this document is not intended to give advice to browser vendors.  If that's the case, what is the above SHOULD doing in the text?  Is there uncertainty as to what implementations do?  If so, it would be better to express that uncertainty, if indeed you are documenting browser behavior.

Also, with respect to this text:

  Though in conflict with
  [RFC6454], current implementations do not consider the port as a
  defining component of the origin.

Does this mean that http://www.foo.com and http://www.foo.com:8080 are considered equivalent, or that http://www.foo.com and http://www.foo.com:80 are _not_ considered equivalent?  What about http://www.foo.com and https://www.foo.com?

The following text is incomprehensible to me as a non-domain-expert:

  The criteria for the SAMEORIGIN option is not evaluated unanimously
  either: one implementation may evaluate the SAMEORIGIN option based
  on the origin of the framed page and the framing page, while another
  may evaluate based on the framed page and the top-level browsing-
  context.

What is the distinction between "top-level browsing context" and "origin of the framing page?"  A reference here would be helpful.

Thanks for documenting this.

[Ballot discuss]
It's interesting to note that this draft says there's a problem with folks not checking the origins of the entire ancestor tree of names of the framing resource - but then doesn't say that sounds like a good idea do it.  I can see the argument that might be made that this draft is just documenting what's done now, but shouldn't we take the opportunity to do more and recommend something along the lines of "The entire ancestor tree of names of the framing resource SHOULD be checked to mitigate the risk of attacks in multiple-nested scenarios" or something like that?

[Ballot comment]
I'd ask about how RFC 6648 applies to this, but I bet this header was out long before the drafts that lead to RFC 6648.

s1 (penultimate paragraph): r/script/Javascript ?

s4.1: Is Figure 1 missing or is that the registration template? ;)

s5:
r/all kinds of these attack vectors/these kind of attack vectors
r/, ...)/)

Appendix A: Is this a guarantee that x-frame-options/frame-options will be supported henceforth until the end of time in those browsers?  Basically, I'm not sure Appendix A is needed.

[Ballot comment]
I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing.

I have one fairly fundamental comment, which I think can be easily addressed, and a few nits.

My comment: This specification starts out like a normal header field specification until you get to

1.  Introduction

  This specification provides informational documentation about the
  current use and definition of the X-Frame-Options HTTP header field.
  Given that the "X-" construction is deprecated [RFC6648], the X
  -Frame-Options header field will in the future be replaced by the
  Frame-Options directive in the Content Security Policy Version 1.1
  [CSP-1-1].

That's still KIND of OK (no indication that anything is wrong with X-FRAME-OPTIONS functionality, just a heads-up that implementations that include X-FRAME-OPTIONS will have work to do in the future), but when we get to

2.3.2.2.  Variation in current browser behaviour

  There are currently variations in the implementation of the X-FRAME-
  OPTIONS header.

we discover unambiguously that current implmentations don't all work the same way, so your ability to rely on X-FRAME-OPTIONS is not entirely clear.

I wonder if the set of technical details are asperational, saying "this is what X-FRAME-OPTIONS could have been, and what the next header field in this space should be".

I think it's fine to publish this specification, especially as Informational, even if it's not clear to me that *any* of the functionality described in this specification is implemented the same way in all major browsers.

I would be more comfortable with a clear statement in the Introduction that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-", but that today's implementations don't all provide the same options with the same behaviors, so relying on this specification as a predictor of what will happen to your frames is not a good idea.

One sentence that puts the reader on notice would be sufficient.

My nits, just so editors don't have to find them again:

Is there a reason why sometimes X-FRAME-OPTIONS is in all caps, and other times not? I'm not an APP guy, so I'm asking.

In Section 2.3.2.2.  Variation in current browser behaviour

  These variations in the evaluation of the header by different
  implementations impair the useage and reliability of this http
  header.  A revised version of x-frame-options in the form of a frame-
  options directive in the CSP 1.1[CSP-1-1] will unify the behaviour
  and it is expected that newer implementations will use it rather than
  the mechanisms documented here"

The trailing quote mark should be a period, I suppose?

5.1.  Privacy Considreations should be "Considerations".

In B.2.  Online Shop Confirm Purchase Page

  The "Confirm Purchase""

The doubled trailing quote marks should be one quote mark, perhaps?

[Ballot comment]
I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing.

I have one fairly fundamental comment, which I think can be easily addressed, and a few nits.

My comment: This specification starts out like a normal header field specification until you get to

1.  Introduction

  This specification provides informational documentation about the
  current use and definition of the X-Frame-Options HTTP header field.
  Given that the "X-" construction is deprecated [RFC6648], the X
  -Frame-Options header field will in the future be replaced by the
  Frame-Options directive in the Content Security Policy Version 1.1
  [CSP-1-1].

That's still KIND of OK (no indication that anything is wrong with X-FRAME-OPTIONS functionality, just a heads-up that implementations that include X-FRAME-OPTIONS will have work to do in the future), but when we get to

2.3.2.2.  Variation in current browser behaviour

  There are currently variations in the implementation of the X-FRAME-
  OPTIONS header.

we discover unambiguously that current implmentations don't all work the same way, so your ability to rely on X-FRAME-OPTIONS is not entirely clear.

I wonder if the set of technical details are asperational, saying "this is what X-FRAME-OPTIONS could have been, and what the next header field in this space should be".

I think it's fine to publish this specification, especially as Informational, even if it's not clear to me that *any* of the functionality described in this specification is implemented the same way in all major browsers.

I would be more comfortable with a clear statement in the Introduction that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-", but that today's implementations don't all provide the same options with the same behaviors, so relying on this specification as a predictor of what will happen to your frames is not a good idea.

One sentence that puts the reader on notice would be sufficient.

My nits, just so editors don't have to find them again:

In Section 2.3.2.2.  Variation in current browser behaviour

  These variations in the evaluation of the header by different
  implementations impair the useage and reliability of this http
  header.  A revised version of x-frame-options in the form of a frame-
  options directive in the CSP 1.1[CSP-1-1] will unify the behaviour
  and it is expected that newer implementations will use it rather than
  the mechanisms documented here"

The trailing quote mark should be a period, I suppose?

5.1.  Privacy Considreations should be "Considerations".

In B.2.  Online Shop Confirm Purchase Page

  The "Confirm Purchase""

The doubled trailing quote marks should be one quote mark, perhaps?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-websec-x-frame-options-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that there is a single action required to be completed upon approval of this document.

In the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

http://www.iana.org/assignments/message-headers

a new message header field name is to be registered as follows:

Header Field Name: X-Frame-Option
Template:
Protocol: http
Status: informational
Reference: [ RFC-to-be ]

NOTE: We will initiate a request and send this to the designated expert
for review.  We will inform you the review result accordingly.

We understand that this is the only action required upon approval of
this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HTTP Header Field X-Frame-Options) to Informational RFC


The IESG has received a request from the Web Security WG (websec) to
consider the following document:
- 'HTTP Header Field X-Frame-Options'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  To improve the protection of web applications against Clickjacking,
  this specification describes the X-Frame-Options HTTP response header
  field that declares a policy communicated from the server to the
  client browser on whether the browser may display the transmitted
  content in frames that are part of other web pages.  This
  informational document serves to document the existing use and
  specification of this X-Frame-Options HTTP response header field.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ballot/


No IPR declarations have been submitted directly on this I-D.

Summary
=======

Yoav Nir is the Document Shepherd. Barry Leiba is the Responsible
Area Director.

This informational document serves to document the existing use and
specification of this X-Frame-Options HTTP response header field.

To improve the protection of web applications against Clickjacking,
this specification describes the X-Frame-Options HTTP response
header field that declares a policy communicated from the server to
the client browser on whether the browser may display the transmitted
content in frames that are part of other web pages. 


Review and Consensus
====================

In 2009 and 2010 many browser vendors introduced the use of a non-
standard HTTP header field "X-Frame-Options" to protect against
Clickjacking. There have been differences between the various
implementations which may cause security and interoperability
concerns. This draft has been produced as informational by the websec
working group to document the current use and also to function as a
baseline for the future unified standard as part of the currently
produced Content Security Policy 1.1 (by WebAppSec at the W3C) - and
to get rid of the deprecated "X-" (see RFC6648).
The review process took sufficient time and involved a medium amount
of people with deep browser security knowledge. During the review
process no major controversies came up, which is not too surprising
as the draft is intended as informational and documenting.


Intellectual Property
=====================

Each author has confirmed conformance with BCPs 78 and 79.
Tobias confirmed. David has also confirmed.

Other Points
============

None.