Re: [websec] FYI: New draft draft-gondrom-frame-options-01

David Ross <dross@microsoft.com> Thu, 07 July 2011 19:36 UTC

Return-Path: <dross@microsoft.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 60EF421F8550 for <websec@ietfa.amsl.com>; Thu, 7 Jul 2011 12:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ0DZlPdBRvH for <websec@ietfa.amsl.com>; Thu, 7 Jul 2011 12:36:18 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFF921F8541 for <websec@ietf.org>; Thu, 7 Jul 2011 12:36:18 -0700 (PDT)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jul 2011 12:36:17 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 7 Jul 2011 12:36:17 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.52]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Thu, 7 Jul 2011 12:36:05 -0700
From: David Ross <dross@microsoft.com>
To: "websec@ietf.org" <websec@ietf.org>, "Tobias Gondrom (tobias.gondrom@gondrom.org)" <tobias.gondrom@gondrom.org>
Thread-Topic: Re: [websec] FYI: New draft draft-gondrom-frame-options-01
Thread-Index: Acw826riqXiyj4iUQzWtC4vxlmLS+A==
Date: Thu, 07 Jul 2011 19:36:04 +0000
Message-ID: <F94D1172DEEC714BBD7F76476442D7151FD3AD46@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [websec] FYI: New draft draft-gondrom-frame-options-01
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: Thu, 07 Jul 2011 19:38:27 -0000

I have some feedback on the FRAME-OPTIONS draft, specifically the ALLOW-FROM syntax.  There are a couple of good arguments against the requirement for a list of trusted origins as opposed to a single trusted origin:

1)  For privacy / security purposes, it would be preferable for the server not to have to explicitly expose the full list of possible frame hosting URLs.

2)  Responses may become bloated when there are a lot of sites in the ALLOW-FROM list.  

3)  Support for wildcards as a solution to list bloat would introduce a new level of complexity w.r.t. parsing, etc.  Even dealing with the delimiter between static URLs in a list can get slightly problematic.

4)  Servers would have to enumerate a list of sites in advance and ensure that the list is actively maintained.  

Relying on custom server-side validation logic instead of permitting lists of origins in ALLOW-FROM would help alleviate these problems.  Eg: Server-side code validating URLs are of the form: https://[five alpha-numeric characters].contoso.com.

Given this, I would suggest a single-origin syntax for ALLOW-FROM similar to X-FRAME-OPTIONS:
http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

---
Note that the Allow-From token does not support wildcards or listing of multiple origins. For cases where the server wishes to allow more than one page to frame its content, the following design pattern is recommended:

1)  The outer IFRAME supplies its own origin information, using a querystring parameter on the Inner IFRAME's src attribute. This can obviously be specified by an attacker, but that's OK.

2)  The server for the Inner IFRAME verifies the supplied Origin information meets whatever criteria business practices call for. For example, the server that serves the IFRAME containing a social network's "Like" button, might check to see that the supplied Origin matches the Origin expected for that Like button, and that the owner of the specified Origin has a valid affiliate relationship, etc.

3)  If satisfied with the information supplied, the server for the Inner IFRAME sends an X-FRAME-OPTIONS: allow-from suppliedorigin header

4)  The Browser then enforces the X-FRAME-OPTIONS directive.
 
If an attacker had specified an origin in step #1 different than the actual origin of the outermost page, he'd be blocked at step #4 when the browser actually enforces the origin.
---

David Ross
dross@microsoft.com