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

[David Ross <[e-mail]>]

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 pattern for server-side validation.  It won't even be particularly obvious that 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 cover this, sorry about that.  I was just anticipating the suggestion of wildcard support as an alternative to a static list.

Your foo.example.com and bar.example.com scenario is probably the most compelling case for the origin list.  Add a few more sites to the example though and the origin list looks less optimal.  I'm optimistic that frameworks could help with the backend complexity of the single-origin scheme.

David Ross
[e-mail]


-----Original Message-----
From: Devdatta Akhawe [mailto:[e-mail]] 
Sent: Thursday, July 07, 2011 6:02 PM
To: David Ross
Cc: [e-mail]; Tobias Gondrom ([e-mail])
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 can just use a single origin for each response.

With regards to (3), why do we even have wildcard support? Why not just a list with no wildcard support ?

If a site wants to allow foo.example.com and bar.example.com, it can just reply with both in the list instead of having to figure out when to reply with foo and when to reply with bar (with the concomitant programming hassle/bugs those cases) or worse reply with *.example.com


thanks
devdatta




> 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-click
> jacking-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]
>
> _______________________________________________
> websec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec
>