[websec] Frame-Options header and intermediate frames

David Ross <dross@microsoft.com> Sat, 18 February 2012 01:14 UTC

Return-Path: <dross@microsoft.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7BF4711E80AE for <websec@ietfa.amsl.com>; Fri, 17 Feb 2012 17:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qtIT8FUqclVa for <websec@ietfa.amsl.com>; Fri, 17 Feb 2012 17:14:14 -0800 (PST)
Received: from AM1EHSOBE002.bigfish.com (am1ehsobe006.messaging.microsoft.com []) by ietfa.amsl.com (Postfix) with ESMTP id C5E9811E808D for <websec@ietf.org>; Fri, 17 Feb 2012 17:14:05 -0800 (PST)
Received: from mail96-am1-R.bigfish.com ( by AM1EHSOBE002.bigfish.com ( with Microsoft SMTP Server id; Sat, 18 Feb 2012 01:14:05 +0000
Received: from mail96-am1 (localhost []) by mail96-am1-R.bigfish.com (Postfix) with ESMTP id 5EB554C00BA; Sat, 18 Feb 2012 01:14:05 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VS0(zzzz1202hzz8275bhz2fh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail96-am1: domain of microsoft.com designates as permitted sender) client-ip=; envelope-from=dross@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail96-am1 (localhost.localdomain []) by mail96-am1 (MessageSwitch) id 1329527643114647_26669; Sat, 18 Feb 2012 01:14:03 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown []) by mail96-am1.bigfish.com (Postfix) with ESMTP id 116D34A0051; Sat, 18 Feb 2012 01:14:03 +0000 (UTC)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com ( by AM1EHSMHS016.bigfish.com ( with Microsoft SMTP Server (TLS) id; Sat, 18 Feb 2012 01:14:02 +0000
Received: from TK5EX14MBXC240.redmond.corp.microsoft.com ([]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([]) with mapi id 14.02.0247.005; Fri, 17 Feb 2012 17:14:00 -0800
From: David Ross <dross@microsoft.com>
To: "Tobias Gondrom (tobias.gondrom@gondrom.org)" <tobias.gondrom@gondrom.org>, IETF WebSec WG <websec@ietf.org>
Thread-Topic: Frame-Options header and intermediate frames
Thread-Index: Aczt143YGrgRy5sXSO+kYLVJtEB9ng==
Date: Sat, 18 Feb 2012 01:14:00 +0000
Message-ID: <68291699F5EA8848B0EAC2E78480571FDF9911@TK5EX14MBXC240.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: Eduardo' Vela <evn@google.com>, Michal Zalewski <lcamtuf@coredump.cx>
Subject: [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 01:14:14 -0000

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:

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

David Ross