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

[Richard Barnes <[e-mail]>]

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

>  On 19/08/13 15:48, Richard Barnes wrote:
>
>
>
>
> On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba <[e-mail]>wrote:
>
>>  > (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.
>>>
>>> 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.
>>
>>
>>   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
>>
>
>  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
>

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
>