Re: [websec] Frame-Options header and intermediate frames

Adam Barth <ietf@adambarth.com> Sat, 18 February 2012 08:07 UTC

Return-Path: <ietf@adambarth.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 60DDA21E8043 for <websec@ietfa.amsl.com>; Sat, 18 Feb 2012 00:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.957
X-Spam-Level:
X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 GKQzAFWf4YYI for <websec@ietfa.amsl.com>; Sat, 18 Feb 2012 00:07:24 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE0F321E8026 for <websec@ietf.org>; Sat, 18 Feb 2012 00:07:23 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so2514774wib.31 for <websec@ietf.org>; Sat, 18 Feb 2012 00:07:22 -0800 (PST)
Received-SPF: pass (google.com: domain of ietf@adambarth.com designates 10.180.101.228 as permitted sender) client-ip=10.180.101.228;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of ietf@adambarth.com designates 10.180.101.228 as permitted sender) smtp.mail=ietf@adambarth.com
Received: from mr.google.com ([10.180.101.228]) by 10.180.101.228 with SMTP id fj4mr3517952wib.4.1329552442450 (num_hops = 1); Sat, 18 Feb 2012 00:07:22 -0800 (PST)
Received: by 10.180.101.228 with SMTP id fj4mr3031497wib.4.1329552442383; Sat, 18 Feb 2012 00:07:22 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id by3sm1990487wib.3.2012.02.18.00.07.20 (version=SSLv3 cipher=OTHER); Sat, 18 Feb 2012 00:07:21 -0800 (PST)
Received: by lahl5 with SMTP id l5so5310282lah.31 for <websec@ietf.org>; Sat, 18 Feb 2012 00:07:20 -0800 (PST)
Received-SPF: pass (google.com: domain of ietf@adambarth.com designates 10.152.132.133 as permitted sender) client-ip=10.152.132.133;
Received: from mr.google.com ([10.152.132.133]) by 10.152.132.133 with SMTP id ou5mr8904671lab.46.1329552440256 (num_hops = 1); Sat, 18 Feb 2012 00:07:20 -0800 (PST)
Received: by 10.152.132.133 with SMTP id ou5mr7444139lab.46.1329552440234; Sat, 18 Feb 2012 00:07:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.100.66 with HTTP; Sat, 18 Feb 2012 00:06:50 -0800 (PST)
In-Reply-To: <68291699F5EA8848B0EAC2E78480571FDF9911@TK5EX14MBXC240.redmond.corp.microsoft.com>
References: <68291699F5EA8848B0EAC2E78480571FDF9911@TK5EX14MBXC240.redmond.corp.microsoft.com>
From: Adam Barth <ietf@adambarth.com>
Date: Sat, 18 Feb 2012 00:06:50 -0800
Message-ID: <CAJE5ia-D+BoFd0v+PAaRPh0g03LWMX_WGeZTfQz-vUSq7h83EQ@mail.gmail.com>
To: David Ross <dross@microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnUHDTF+NRs1MB2VuoDoq1Zla04fc+0RuPMHqZZ4+UPKHOnPtwTTeyuv41IBrzGp+ZWIt9W
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:07:25 -0000

On Fri, Feb 17, 2012 at 5:14 PM, David Ross <dross@microsoft.com> wrote:
> Michal Zalewski and Eduardo Vela brought up an interesting scenario pertaining to the Frame-Options header.  Specifically, if only the top level page URL is validated w.r.t. SAMEORIGIN or ALLOW-FROM, malicious ads or other unsafe content in an intermediate frame could re-frame content from the top level site for the purposes of clickjacking.
>
> In the RFC draft currently there is the following:
>
> ---
> SAMEORIGIN
> ...
>        [TBD]current implementations do not display if the origin of
>        the top-level-browsing-context is different than the origin of
>        the page containing the FRAME-OPTIONS header.
> ---
>
> There'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, but I'm not sure how worried we should be about the
aesthetics.

Adam