Subject: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

From: "Richard Barnes" <[email-masked]>
Date: Wed, 14 Aug 2013 18:41:21 -0700

Richard Barnes has entered the following ballot position for
draft-ietf-websec-x-frame-options-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
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). 
"""

---

From: "Hill, Brad" <[email-masked]>
Date: Fri, 16 Aug 2013 23:44:16 +0000

Additional comments inline.
________________________________________

[Hill, Brad] Agreed.

[Hill, Brad]  This really does mean the top/final origin value in a frame ancestor
chain walk.  Browsers have implemented X-Frame-Options to check the 
Origin context that is topmost in the window or tab.  (the _top target, 
representing the full, original browsing context, not just the immediate 
parent frame)  This could be clarified perhaps, but is not incorrect.

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 17 Aug 2013 23:45:44 +0100

Dear Richard,

thanks for the review and your discusses and comments.
Answers inline.
I followed all your suggestions in version-10, except for D2.
Thanks for the review and all the best,

Tobias

> http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/
Yes.
Ok. I expanded the text and explanation of the privacy considerations
section accordingly.

> is something browsers do today, please say so.  

Actually I like to push back in this case, as I don't think we should go
into implementation specific details that have no effect on the bits on
the wire nor on the effective behavior of the browser.
The X-Frame-Options header determines the behaviour for every individual
requested page regarding framing in another web page in the browser.
Whether the browser caches this information and compares the request
with an existing cache from a request from before AND if the value is
identical proceeds as before or whether the browser evaluates the
X-Frame-Options header on each request should not be specified in this
draft.

> https://example.com/this/is/a/path?query#fragment"?  

Yes. You are right we can refine the definition to "serialized-origin"
(as a subset of URI).
Please note that according to RFC6454 we need to use "serialized-origin"
here and not origin (as origin in RFC6454 refers also to a list of
origins, which would not be acceptable here).
I adjusted the text accordingly.

Note: From an editorial standpoint we can debate whether to use lower
case "serialized-origin" or capital "SERIALIZED-ORIGIN". RFC6454 uses
lower case. So I used that one, but I am open for either.

> really mean the top level here, as opposed to the next one up?  
Yes. And unfortunately with the problems you outlined in the next
sentence (which are also described in the security considerations
sections of the draft.)
Ted raised a related comment. So I guess the current text regarding
nesting and potential problem is not sufficiently clear. So I will add
further explanations. And I will add a reference to the security
considerations section which already contains a paragraph about this
problem. (i.e. the 2nd paragraph).

> For
I added text accordingly to section 5.
(and I initiated a research query to re-confirm again that we still have
the two inconsistent browser behaviour cases here (framing page vs.
top-level frame, as I wrote in the draft).

Ok. removed.

> the ALLOW-FROM URI (in the case of ALLOW-FROM). 
Thank you. I changed the text to your suggestion.

>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Aug 2013 01:58:53 -0400

> X-Frame-Options header on each request should not be specified in this

 I'll note also that this is particularly the case because this is
documenting something that exists, but that isn't recommended for
implementation.  If this were a PS that we were recommending for new
implementations, it might make more sense to talk about how to do caching
for better implementations.

Barry

---

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Aug 2013 19:40:11 +0000

Hi Richard.

Please see below. Do the changes address your concerns?

Yoav

The text for Privacy Considerations has changed
OLD:
   The parameter ALLOW-FROM allows a page to guess who is framing it.
   This is inherent by design, but may lead to data leakage or data
   protection concerns.
NEW:
   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 by thus determine which other page is framing it.
       This is inherent by design, but may lead to data leakage or data
       protection concerns.

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

> is something browsers do today, please say so.  

Since Tobias is arguing this (  ), I'll leave this one alone for now, but please let us know if you've been convinced.

> https://example.com/this/is/a/path?query#fragment"?  

OLD:
   ALLOW-FROM  (followed by a URI [RFC3986] of a trusted origin)
NEW:
   ALLOW-FROM  (followed by a serialized-origin [RFC6454])

> if the answer is A, then C is trusting A not to load any malicious

New (in sectin 2.3.2.2):
   To illustrate the difference between the comparison with "framing
   page" and the "top-level browsing-context" consider the following
   scenario: Web pages may embed frames with other pages which 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 in a frame web page B, and web page B contains in a
   frame web page C.

   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"

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 09:38:16 -0400

> Additional comments inline.

Great.

> parent frame)  This could be clarified perhaps, but is not incorrect.

OK, that's fine.  Could you please just note the risk that an intermediate
frame in a nested scenario could do bad things?  For example, in the
Security Considerations:
"""
When SAMEORIGIN or ALLOW-FROM values are used, there is some residual risk
in nested framing scenarios.  For example, suppose that A loads B in an
iframe; B loads C; and C sends an X-Frame-Options header with the value
"ALLOW-FROM A".  The browser will allow this setup, because the ALLOW-FROM
origin sent by C matches the top-level origin.  However, the intermediate
framing page B may still be able to perform clickjacking attacks against A.
 Thus, sites using this mechanism should keep in mind that by emitting an
X-Frame-Options header with value SAMEORIGIN or ALLOW-FROM, they are not
only granting permission to the indicated origin (the same origin, or the
ALLOW-FROM origin), but also to any origins included as frames within that
origin.
"""

Thanks,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 09:45:44 -0400

> X-Frame-Options header on each request should not be specified in this

I get this.  I'm actually just asking for some clarification about what
browsers do -- whether they do or don't cache X-Frame-Options settings.  It
seems like something that could cause problems for web site operators, so
it would be helpful to know.  Not looking for any normative text here.

> lower case. So I used that one, but I am open for either.

It seems like the ABNF in this document should just import the ABNF from RF
6454.  So, "serialized-origin".

> top-level frame, as I wrote in the draft).

Great, that should be fine.  I've gone ahead and cleared this point.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 09:46:39 -0400

> ALLOW-FROM origin), but also to any origins included as frames within that

Update: Feel free to ignore this suggestion (or steal text if you think
it's helpful).  I think Tobias is on the right track with what he
suggested.  That's what I get for responding to email in chronological
order :)

--Ricahrd

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 09:48:39 -0400

> for better implementations.

I understand.  Caching is just another aspect of existing implementation
behavior that I think should be documented.

Of course, I may be off base here.  If nobody does it, and people think
it's patently obvious that you never would, then I could clear.

--Richard

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 19 Aug 2013 16:41:49 +0200

On 19/08/13 15:48, Richard Barnes wrote:
>
>
>
> On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     implementation.  If this were a PS that we were recommending for
>     new implementations, it might make more sense to talk about how to
>     do caching for better implementations.
>
>     Barry
>
>
> I understand.  Caching is just another aspect of existing
> implementation behavior that I think should be documented.  
>
> Of course, I may be off base here.  If nobody does it, and people
> think it's patently obvious that you never would, then I could clear. 
>
> --Richard
>

Richard,

in short: I think, we really don't need and in fact should not discuss
caching of the existing implementations in this draft.

Some info fyi:
caching has only very limited (or no) benefit here. Because the browser
has to check for every http-request of the resource whether the
X-Frame-Options header has been set and then act accordingly. It is also
a very simple check.

And consider as a page itself might be dynamic, the header can change
with it, too.

As mentioned in my answer before the only mini advantage of caching
might be that the browser sees the header is still the same as before
(with a simple TRUE/FALSE regex) and then doesn't have to evaluate the
ruleset again e.g. if ALLOW-FROM is set if you already did so in your
previous call.
But nearly all of the X-Frame-Options requests are DENY or SAMEORIGIN in
which case the comparison of the header with the previous one would not
be much cheaper than to just run the regex rule for the header itself.

And also, as outlined in section 2.3.2.3., servers may generate
X-Frame-Options header responses depending on the request.
Example case: Consider that we have only one serialized-origin in the
ALLOW-FROM directive. Now imagine a user has multiple pages open in his
browser tabs with one of web page 1 from domain A and the second of web
page 2 from domain B 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, the first pointing to
origin A, the second to origin B.
But then many implementations don't support the ALLOW-FROM directive....

So to summarize my answer: we really don't need and in fact should not
discuss caching of the existing implementations.

All the best, Tobias

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 19 Aug 2013 16:44:13 +0200

On 19/08/13 15:46, Richard Barnes wrote:
>
>
>
> On Mon, Aug 19, 2013 at 9:38 AM, Richard Barnes <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>
>     On Fri, Aug 16, 2013 at 7:44 PM, Hill, Brad <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     OK, that's fine.  Could you please just note the risk that an
>     intermediate frame in a nested scenario could do bad things?  For
>     example, in the Security Considerations:
>     """
>     When SAMEORIGIN or ALLOW-FROM values are used, there is some
>     residual risk in nested framing scenarios.  For example, suppose
>     that A loads B in an iframe; B loads C; and C sends an
>     X-Frame-Options header with the value "ALLOW-FROM A".  The browser
>     will allow this setup, because the ALLOW-FROM origin sent by C
>     matches the top-level origin.  However, the intermediate framing
>     page B may still be able to perform clickjacking attacks against
>     A.  Thus, sites using this mechanism should keep in mind that by
>     emitting an X-Frame-Options header with value SAMEORIGIN or
>     ALLOW-FROM, they are not only granting permission to the indicated
>     origin (the same origin, or the ALLOW-FROM origin), but also to
>     any origins included as frames within that origin.
>     """
>
>
> Update: Feel free to ignore this suggestion (or steal text if you
> think it's helpful).  I think Tobias is on the right track with what
> he suggested.  That's what I get for responding to email in
> chronological order :)
>
> --Ricahrd

Dear Richard,
no problem, happens to me, too.
Synchronous and asynchronous processing. ;-)

I will keep the new revised wording in version-10 as is.

Thanks, Tobias

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 11:42:13 -0400

On Mon, Aug 19, 2013 at 10:41 AM, Tobias Gondrom <[email-masked]
> wrote:

> X-Frame-Options header has been set and then act accordingly. It is also a
> very simple check.
>
> And consider as a page itself might be dynamic, the header can change with
> it, too.
>
> As mentioned in my answer before the only mini advantage of caching might
> be that the browser sees the header is still the same as before (with a
> simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset
> again e.g. if ALLOW-FROM is set if you already did so in your previous
> call.
> which case the comparison of the header with the previous one would not be
> much cheaper than to just run the regex rule for the header itself.
>
> ALLOW-FROM directive. In that case the page needs to reply to both requests
> with different X-Frame-Options headers, the first pointing to origin A, the
> second to origin B.

Again, I'm not looking for an analysis of the merits here, just what
current browsers do.  It looks like Firefox doesn't cache anything [1], but
I don't know about other browsers.  If anyone does, then this document
should warn people.  If there are no known instances of caching, I'll just
clear.

In a related vein, the code below demonstrates that at least Firefox *will*
accept a URI with ALLOW-FROM, and (correctly) do the comparison based on
the origin of that URI.  If other browsers do this, then with regard to
(D3), it seems this document should probably say that the header *syntax*
allows a URI, but the *comparison* is done based on the origin of the URI
(Section 4 of RFC 6454).

Thanks,
--Richard

[1] <
http://dxr.mozilla.org/mozilla-central/source/docshell/base/nsDSURIContentListener.cpp#l361

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Aug 2013 13:43:29 -0400

Richard:

1. I disagree with you, but more to the point...

2. ...do you really think this meets the DISCUSS criteria?

Barry

On Mon, Aug 19, 2013 at 11:42 AM, Richard Barnes <[email-masked]> wrote:
>
>
>
> On Mon, Aug 19, 2013 at 10:41 AM, Tobias Gondrom
> <[email-masked]> wrote:
>>
>> simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset again
>> e.g. if ALLOW-FROM is set if you already did so in your previous call.
>> browser tabs with one of web page 1 from domain A and the second of web page
>> 2 from domain B 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, the first pointing to origin A, the
>> second to origin B.
> Again, I'm not looking for an analysis of the merits here, just what current
> browsers do.  It looks like Firefox doesn't cache anything [1], but I don't
> know about other browsers.  If anyone does, then this document should warn
> people.  If there are no known instances of caching, I'll just clear.
>
> accept a URI with ALLOW-FROM, and (correctly) do the comparison based on the
> origin of that URI.  If other browsers do this, then with regard to (D3), it
> seems this document should probably say that the header *syntax* allows a
> URI, but the *comparison* is done based on the origin of the URI (Section 4
> of RFC 6454).
>
> Thanks,
> --Richard
>
> [1]
> <http://dxr.mozilla.org/mozilla-central/source/docshell/base/nsDSURIContentListener.cpp#l361>
>

---

From: "Hill, Brad" <[email-masked]>
Date: Mon, 19 Aug 2013 19:31:07 +0000

I received a question as to whether all browsers really implement the top-level only check, or if any do an immediate parent or ancestor walk.  I could guess, but I'd rather test.  Here's a test case for public use:

http://webappsec-test.info/~bhill2/XFO/XFO_Top.html

I checked the latest IE, Chrome, Opera and Firefox and they all render the innermost frame. (don't have a Safari instance handy at the moment to test but welcome others' reports)

-Brad
________________________________________
From: Hill, Brad
Sent: Friday, August 16, 2013 4:44 PM
To: Richard Barnes; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [websec] Richard Barnes' Discuss on        draft-ietf-websec-x-frame-options-09:   (with DISCUSS and COMMENT)

[Hill, Brad] Agreed.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 16:24:01 -0400

Safari also renders the innermost frame.

On Mon, Aug 19, 2013 at 3:31 PM, Hill, Brad <[email-masked]> wrote:

> I received a question as to whether all browsers really implement the
> top-level only check, or if any do an immediate parent or ancestor walk.  I
> could guess, but I'd rather test.  Here's a test case for public use:
>
> I checked the latest IE, Chrome, Opera and Firefox and they all render the
> innermost frame. (don't have a Safari instance handy at the moment to test
> but welcome others' reports)
>
> -Brad
> Subject: RE: [websec] Richard Barnes' Discuss on
>  draft-ietf-websec-x-frame-options-09:   (with DISCUSS and COMMENT)
>

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 19 Aug 2013 22:27:23 +0200

> I checked the latest IE, Chrome, Opera and Firefox and they all render the innermost frame. (don't have a Safari instance handy at the moment to test but welcome others' reports)

I just tested Safari and can confirm that they do render the innermost
frame. (i.e. render based on the top-level frame.)

Strangely: I found in my old notes from the first version of the draft
from 2011/2012 that not all browsers would use the same algorithm for
X-Frame-Options: SAMEORIGIN. But obviously they do now (as tested and
verified).

I will adjust the text in version -11 for section 5 accordingly and
remove in section 5 sub-bullet a).

Special thanks to Brad for creating the test web page and cross-verifying.

Thanks, Tobias

Ps.: apologies, it may take up to 48 hours for me to submit the new text
for version-11 as I will have a busy work day tomorrow. :-(

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 Aug 2013 16:27:49 -0400

My understanding of the goal of "existing state of the art" documents like
this is to enable users of the relevant technology to understand how it
behaves.  If there is caching behavior, then users need to know about it
(in particular, web sites that might set X-Frame-Options).  This seems like
a potentially significant interop issue, so I was going to hold the DISCUSS
until someone told me whether there's an issue there or not, i.e., whether
there's any caching behavior out in the wild.

--Richard

On Mon, Aug 19, 2013 at 1:43 PM, Barry Leiba <[email-masked]>wrote:

> with
> might
> again
> be
> page
> current
> the
> > <