IETF Logo Mail Archive

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

Yoav Nir <ynir@checkpoint.com> Sun, 18 August 2013 19:40 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1A411E8169; Sun, 18 Aug 2013 12:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.563
X-Spam-Level:
X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll1sYL6wcn0F; Sun, 18 Aug 2013 12:40:15 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D45D911E811F; Sun, 18 Aug 2013 12:40:14 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7IJeCa7025291; Sun, 18 Aug 2013 22:40:12 +0300
X-CheckPoint: {5211231C-14-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Sun, 18 Aug 2013 22:40:11 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Richard Barnes <rlb@ipv.sx>
Thread-Topic: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)
Thread-Index: AQHOmViW1PGmiLYYbkq+EYlkkkwLXpmbMImA
Date: Sun, 18 Aug 2013 19:40:11 +0000
Message-ID: <3BD7F636-F3DA-4204-AC23-68F868FFD4D7@checkpoint.com>
References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com>
In-Reply-To: <20130815014121.17800.33179.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.83]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 1170fca780dc57c889946b24fb4d53df9d99ece634
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0028F4E458601F49889C93F4142C3B9D@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<draft-ietf-websec-x-frame-options@tools.ietf.org>" <draft-ietf-websec-x-frame-options@tools.ietf.org>, "<websec@ietf.org>" <websec@ietf.org>, The IESG <iesg@ietf.org>, "<websec-chairs@tools.ietf.org>" <websec-chairs@tools.ietf.org>
Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Aug 2013 19:40:21 -0000

Hi Richard.

Please see below. Do the changes address your concerns?

Yoav


On Aug 15, 2013, at 4:41 AM, Richard Barnes <rlb@ipv.sx> wrote:

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

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.

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

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

> (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"?  

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

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

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"

v2.23.0 | Report a Bug | By Email