From: David Ross <dross@microsoft.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Thread-Topic: [websec] FYI: New draft draft-gondrom-frame-options-01
Thread-Index: AQHMPQqs25ue1XmKxUOxDyUVQzUsxZThqf5Q
Date: Fri, 8 Jul 2011 02:19:55 +0000
Message-ID: <F94D1172DEEC714BBD7F76476442D7151FD3BCB9@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
References: <F94D1172DEEC714BBD7F76476442D7151FD3AD46@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
 <CAPfop_0LNvpxtxPuZDVUGOYH-05ZKYNvu0Os1Tjr6TWdPjFg-g@mail.gmail.com>
In-Reply-To: <CAPfop_0LNvpxtxPuZDVUGOYH-05ZKYNvu0Os1Tjr6TWdPjFg-g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "websec@ietf.org" <websec@ietf.org>
Subject: Re: [websec] FYI: New draft draft-gondrom-frame-options-01
Precedence: list

I think that if the multi-origin syntax is available and common in examples=
, web developers won't really have an incentive to implement the design pat=
tern for server-side validation.  It won't even be particularly obvious tha=
t it's an option.  So I worry that we'd begin to see a whole lot of (1), (2=
), and (4) out on the web.

(3) below is a little confusing because the draft RFC doesn't actually cove=
r this, sorry about that.  I was just anticipating the suggestion of wildca=
rd support as an alternative to a static list.

Your foo.example.com and bar.example.com scenario is probably the most comp=
elling case for the origin list.  Add a few more sites to the example thoug=
h and the origin list looks less optimal.  I'm optimistic that frameworks c=
ould help with the backend complexity of the single-origin scheme.

David Ross
dross@microsoft.com


-----Original Message-----
From: Devdatta Akhawe [mailto:dev.akhawe@gmail.com]=20
Sent: Thursday, July 07, 2011 6:02 PM
To: David Ross
Cc: websec@ietf.org; Tobias Gondrom (tobias.gondrom@gondrom.org)
Subject: Re: [websec] FYI: New draft draft-gondrom-frame-options-01

I don't understand. A list of origins also allows a list of only one, right=
? (1), (2), (4) don't seem to be an issue: a server concerned about them ca=
n just use a single origin for each response.

With regards to (3), why do we even have wildcard support? Why not just a l=
ist with no wildcard support ?

If a site wants to allow foo.example.com and bar.example.com, it can just r=
eply with both in the list instead of having to figure out when to reply wi=
th foo and when to reply with bar (with the concomitant programming hassle/=
bugs those cases) or worse reply with *.example.com


thanks
devdatta




> 1) =A0For privacy / security purposes, it would be preferable for the ser=
ver not to have to explicitly expose the full list of possible frame hostin=
g URLs.
>
> 2) =A0Responses may become bloated when there are a lot of sites in the A=
LLOW-FROM list.
>
> 3) =A0Support for wildcards as a solution to list bloat would introduce a=
 new level of complexity w.r.t. parsing, etc. =A0Even dealing with the deli=
miter between static URLs in a list can get slightly problematic.
>
> 4) =A0Servers would have to enumerate a list of sites in advance and ensu=
re that the list is actively maintained.
>
> Relying on custom server-side validation logic instead of permitting list=
s of origins in ALLOW-FROM would help alleviate these problems. =A0Eg: Serv=
er-side code validating URLs are of the form: https://[five alpha-numeric c=
haracters].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-click
> jacking-with-x-frame-options.aspx
>
> ---
> Note that the Allow-From token does not support wildcards or listing of m=
ultiple origins. For cases where the server wishes to allow more than one p=
age to frame its content, the following design pattern is recommended:
>
> 1) =A0The outer IFRAME supplies its own origin information, using a query=
string parameter on the Inner IFRAME's src attribute. This can obviously be=
 specified by an attacker, but that's OK.
>
> 2) =A0The server for the Inner IFRAME verifies the supplied Origin inform=
ation 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 fo=
r that Like button, and that the owner of the specified Origin has a valid =
affiliate relationship, etc.
>
> 3) =A0If satisfied with the information supplied, the server for the=20
> Inner IFRAME sends an X-FRAME-OPTIONS: allow-from suppliedorigin=20
> header
>
> 4) =A0The Browser then enforces the X-FRAME-OPTIONS directive.
>
> If an attacker had specified an origin in step #1 different than the actu=
al origin of the outermost page, he'd be blocked at step #4 when the browse=
r actually enforces the origin.
> ---
>
> David Ross
> dross@microsoft.com
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>