Re: [websec] Frame-Options header and intermediate frames
Giorgio Maone <g.maone@informaction.com> Sat, 18 February 2012 08:33 UTC
Return-Path: <g.maone@informaction.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 2ED6221F85FB for <websec@ietfa.amsl.com>; Sat, 18 Feb 2012 00:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 me1w1ht1Zbac for <websec@ietfa.amsl.com>; Sat, 18 Feb 2012 00:33:06 -0800 (PST)
Received: from mail2.informaction.com (mail2.informaction.com [82.103.137.214]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F721F85F6 for <websec@ietf.org>; Sat, 18 Feb 2012 00:33:00 -0800 (PST)
Received: (qmail 4619 invoked by uid 89); 18 Feb 2012 08:32:56 -0000
Received: by simscan 1.4.0 ppid: 4612, pid: 4615, t: 0.1402s scanners: attach: 1.4.0 clamav: 0.97.2
/m: 54/d:13845
Received: from unknown (HELO ?192.168.1.196?) (g.maone@informaction.com@217.133.105.229) by ariel.informaction.com with ESMTPA; 18 Feb 2012 08:32:56 -0000
Message-ID: <4F3F623A.9060200@informaction.com>
Date: Sat, 18 Feb 2012 09:32:58 +0100
From: Giorgio Maone <g.maone@informaction.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <68291699F5EA8848B0EAC2E78480571FDF9911@TK5EX14MBXC240.redmond.corp.microsoft.com> <CAJE5ia-D+BoFd0v+PAaRPh0g03LWMX_WGeZTfQz-vUSq7h83EQ@mail.gmail.com>
In-Reply-To: <CAJE5ia-D+BoFd0v+PAaRPh0g03LWMX_WGeZTfQz-vUSq7h83EQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Eduardo' Vela <evn@google.com>, IETF WebSec WG <websec@ietf.org>, Michal Zalewski <lcamtuf@coredump.cx>
Subject: Re: [websec] Frame-Options header and intermediate frames
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: Sat, 18 Feb 2012 08:33:07 -0000
On 18/02/2012 09:06, Adam Barth wrote: > On Fri, Feb 17, 2012 at 5:14 PM, David Ross<dross@microsoft.com> wrote: here's a good argument that sites attempting to avoid attacks such as phishing and clickjacking would not want to frame arbitrary content. Users really only have an easy way to make immediate and valid trust decisions about the origin of the top level page, not frames contained within those pages. But sites that frame arbitrary content do exist in the real world, for better or worse. While there are different philosophical viewpoints on cross-domain framing, there doesn't seem to be any reason to avoid creating a ValidateAllAncestors flag on Frame-Options which would instruct the browser to validate the URL of each hosting frame up to the top level. Given this, sites that frame arbitrary content could at least make use of SAMEORIGIN and ALLOW-FROM for their intended purpose. >> >> We'd like to get the intermediate frame issue documented and describe the optional ValidateAllAncestors flag in the RFC draft. > > That sounds like a reasonable way to extend the existing syntax. It's > slightly ugly Would just "AllAncestors" be clear enough? -- G
- [websec] Frame-Options header and intermediate fr… David Ross
- Re: [websec] Frame-Options header and intermediat… Adam Barth
- Re: [websec] Frame-Options header and intermediat… Giorgio Maone
- Re: [websec] Frame-Options header and intermediat… David Ross
- Re: [websec] Frame-Options header and intermediat… Tobias Gondrom