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

[Devdatta Akhawe <[e-mail]>]

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