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

[David Ross <[e-mail]>]

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
[e-mail]