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

Tobias Gondrom <tobias.gondrom@gondrom.org> Mon, 19 August 2013 20:27 UTC

Return-Path: <tobias.gondrom@gondrom.org>
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 B853521F90FD for <websec@ietfa.amsl.com>; Mon, 19 Aug 2013 13:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.362
X-Spam-Level:
X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
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 KKHzjE7g7r8m for <websec@ietfa.amsl.com>; Mon, 19 Aug 2013 13:27:32 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8286611E82DA for <websec@ietf.org>; Mon, 19 Aug 2013 13:27:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=S5e8XNODGg6wjMUkt6hu8stSzO6zXR1jCnc3Dzpvs8pG172SMLSRymkyzHWSYvPc+YOC0Ls1bI/a0YVSErcQwInjMTPeOTz2n/zoxPgy0qTjLB7iIXvhxQes+g0HgncP; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 14004 invoked from network); 19 Aug 2013 22:27:25 +0200
Received: from port-83-236-131-2.static.qsc.de (HELO ?10.13.163.52?) (83.236.131.2) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2013 22:27:24 +0200
Message-ID: <52127FAB.4020501@gondrom.org>
Date: Mon, 19 Aug 2013 22:27:23 +0200
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: bhill@paypal-inc.com
References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com>, <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@DEN-EXDDA-S12.corp.ebay.com> <370C9BEB4DD6154FA963E2F79ADC6F2E27BAF121@DEN-EXDDA-S12.corp.ebay.com>
In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E27BAF121@DEN-EXDDA-S12.corp.ebay.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@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: Mon, 19 Aug 2013 20:27:45 -0000

On 19/08/13 21:31, Hill, Brad 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:
>
> 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)

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


>
> -Brad
> ________________________________________
> From: Hill, Brad
> Sent: Friday, August 16, 2013 4:44 PM
> To: Richard Barnes; The IESG
> Cc: draft-ietf-websec-x-frame-options@tools.ietf.org; websec@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)
>
> Additional comments inline.
> ________________________________________
>
>
> (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"?
>
> [Hill, Brad] Agreed.
>
>
> (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.
>
> [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.
>