Subject: Re: [websec] WGLC for X-Frame-Options

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Nov 2012 23:19:45 +0000

Here is my review (with my co-chair hat off):

[RFC3986] should be a Normative reference (as it is required to 
parse/generate
a valid X-Frame-Options header field).

[RFC6454] is normative, because there is a SHOULD requirement to use it.

In Section 2.1:

   The ALLOW-FROM URI MUST be valid.

I don't know what this mean exactly. Can you elaborate?

2.2.  Backus-Naur Form (BNF)

    The RFC 822 [RFC0822] EBNF of the X-Frame-Options header is:

Which makes [RFC0822] Normative.

          X-Frame-Options = "Frame-Options" ":" "DENY"/ "SAMEORIGIN" /
                                  ("ALLOW-FROM" ":" URI)

    With URI as defined in [RFC3986]
    [TBD] Or should we use the ABNF (RFC 2234) alternatively to EBNF or
    in addition?

Yes, you should use RFC 5234. This probably means inserting "[WSP]" in 
various
places, but I think that would be much better.

2.3.2.  Browser Behaviour and Processing

    To allow secure implementations, browsers MUST behave in a consistent
    and reliable way.

This is self evident, IMHO, and I don't think it adds much value. How 
exactly
violation or conformance to this MUST be verified? I suggest deleting 
the sentence.

2.4.1.  Example scenario for the ALLOW-FROM parameter

    1.  Inner IFRAME suggests via a querystring parameter what site it
        wants to be hosted by.  This can obviously be specified by an
        attacker, but that's OK.

I blame lack of sleep, but can you explain this to me in more details?

5.  Security Considerations

    The introduction of the http header X-FRAME-OPTIONS does improve the
    protection against Clickjacking, however it is not self-sufficient on
    its own but MUST be used in conjunction with other security measures
    like secure coding and Content Security Policy (CSP)

CSP needs an Informative reference.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Nov 2012 17:26:06 +0100

On 2012-11-06 00:19, Alexey Melnikov wrote:
> ...

Almost.

You should reference HTTPbis Part 1, and, in particular, *only* define 
the ABNF for the field value.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Nov 2012 18:25:43 +0100

Hi there,

here's my feedback from the HTTP/editorial point of view:

> Abstract
>
>    To improve the protection of web applications against Clickjacking
>    this standard defines an http response header that declares a policy

s/standard/specification/
s/http response header/HTTP response header field/

>    communicated from a host to the client browser on whether the browser
>    must not display the transmitted content in frames of other web
>    pages.  This drafts serves to document the existing use and

drafts?

>    In 2009 and 2010 many browser vendors ([Microsoft-X-Frame-Options],
>    [CLICK-DEFENSE-BLOG], [Mozilla-X-Frame-Options]) introduced the use
>    of a non-standard http header RFC 2616 [RFC2616] "X-Frame-Options" to

s/http header RFC 2616 [RFC2616]/HTTP [RFC2616] header field/

>    protect against Clickjacking [Clickjacking].  This draft is to
>    document the current use of X-Frame-Options header and shall in the
>    future be replaced by the Frame-Options [FRAME-OPTIONS] standard.

What's supposed to be replaced is the header field, not the spec, right?

> 2. X-Frame-Options Header
>
>
>    The X-Frame-Options HTTP response header indicates a policy whether a

s/header/header field/ throughout.

>    browser MUST NOT allow to render a page in a <frame> or <iframe> .

whitespace...

> 2.1. Syntax
>
>
>    The header field name is:
>    X-Frame-Options
>
>    There are three different values for the header field.  These values
>    are exclusive, that is NOT more than one of the three values MUST be
>    set.

maybe "exactly one"?

>    DENY
>          A browser receiving content with this header MUST NOT display
>          this content in any frame.
>
>    SAMEORIGIN
>          A browser receiving content with this header MUST NOT display
>          this content in any frame from a page of different origin than
>          the content itself.

Reference ORIGIN spec?

>    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
>          contex 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.
>          For example: X-FRAME-OPTIONS: ALLOW-FROM:
>          https://www.domain.com/

The example needs reformatting.

>    Any data beyond the domain address (i.e. any data after the "/"
>    separator) is to be ignored.  And the algorithm to compare origins

authority component?

>    from [RFC6454] SHOULD be used to verify 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.
>
>    Wildcards or lists to declare multiple domains in one ALLOW-FROM
>    statement are not permitted.
>
>    Please note that in conflict with [RFC6454], current implementations
>    do not consider the port as a defining component of the origin.
>

That should reference HTTPbis P1, and just define the field *value, such as:

X-Frame-Options = "DENY"
                 / "SAMEORIGIN"
                 / ( "ALLOW-FROM" OWS ":" OWS URI )
OWS = <HTTPbis P1 ref>
URI = <RFC3986 ref>

Note that this makes the keywords case-insensitive; if this is intended 
it might make sense to call it out. Otherwise, the ABNF needs to be fixed.

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

I'm pretty sure you need normative references for HTTP, ABNF and URI.

Best regards, Julian

---

From: "Hill, Brad" <[email-masked]>
Date: Thu, 8 Nov 2012 19:50:40 +0000

In "2.3.1.  Enable HTML content from other domains", the object tag is mentioned in addition to frame and iframe.  This list should also include the applet and embed tags, although user agent behavior may not be consistent on this.

In "5. Security Considerations", it should be mentioned that current implementations do not check the entire ancestor tree of the protected resource, and this may expose the resource to attack in multiply-nested scenarios.  For example, if a resource on 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 will pass if the user agent only verifies the top-level browsing context.

It should also probably be mentioned that X-Frame-Options MUST be sent as an HTTP header and is explicitly ignored by user agents when declared with a meta http-equiv tag.

-Brad Hill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yoav Nir
> Sent: Tuesday, October 23, 2012 6:40 PM
> To: IETF WebSec WG
> Subject: [websec] WGLC for X-Frame-Options
> 
> Hi all
> 
> This is to initiate WGLC for the X-Frame-Options draft (not to be confused
> with the Frame-Options draft).
> 
> Please go to http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01,
> read the draft and send comments.
> 
> As usual, we would very much like to hear comments about clarity,
> thoroughness and applicability. Since this draft documents existing behavior,
> rather than prescribing future behavior, we would especially like to hear from
> people familiar with current implementations that support the X-Frame-
> Option header about whether the draft accurately describes the behavior of
> those implementations.
> 
> WGLC is usually for two weeks. However, the following two weeks include an
> IETF meeting, so I am extending this period to a little over three weeks. WGLC
> will end on Friday, November 16th. Please send your comments early, so that
> we might use our session in Atlanta to discuss issues that come up.
> 
> Yoav
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Nov 2012 08:09:29 +0000

Reminder: WGLC ends this Friday. Please send in your reviews.

On Oct 24, 2012, at 12:39 AM, Yoav Nir wrote:

> Hi all
> 
> This is to initiate WGLC for the X-Frame-Options draft (not to be confused with the Frame-Options draft).
> 
> Please go to http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01, read the draft and send comments.
> 
> As usual, we would very much like to hear comments about clarity, thoroughness and applicability. Since this draft documents existing behavior, rather than prescribing future behavior, we would especially like to hear from people familiar with current implementations that support the X-Frame-Option header about whether the draft accurately describes the behavior of those implementations.
> 
> WGLC is usually for two weeks. However, the following two weeks include an IETF meeting, so I am extending this period to a little over three weeks. WGLC will end on Friday, November 16th. Please send your comments early, so that we might use our session in Atlanta to discuss issues that come up.
> 
> Yoav

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Nov 2012 10:31:22 -0700

On 10/23/12 4:39 PM, Yoav Nir wrote:

> This is to initiate WGLC for the X-Frame-Options draft

Lacking time for a thorough review, I'll provide only a few small
suggestions (take them or leave them as you will)...

Abstract

"this standard defines" => "this document defines"

Introduction

OLD
This draft is to document the current use of X-Frame-Options header
and shall in the future be replaced by the Frame-Options
[FRAME-OPTIONS] standard.

NEW
This specification provides informational documentation about the
current definition and use of the X-Frame-Options header.  Given that
the "X-" construction is deprecated [RFC6648], the X-Frame-Options
header will in the future be replaced by the Frame-Options
[FRAME-OPTIONS] header.

[note: I'm not sure if the migration from X-Frame-Options to
Frame-Options is really motivated by the considerations in RFC 6648,
thus you might not want to include the first clause of the second
sentence above]

IANA Considerations

Does this header really belong in the permanent registry, given that
there are already plans to deprecate it?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/