Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

[Tobias Gondrom <[e-mail]>]

Jeff,
thank you very much for the review.
Will add missing references in version -02.

- Tobias


On 08/07/11 05:38, =JeffH wrote:
>
> Hi Tobias -- thanks for working on this spec, it will be good to get 
> this all more formally documented.
>
> It appears that the -01 rev of draft-gondrom-frame-options takes into 
> account the apparently present X-Frame-Options documentation here..
>
>
> [2] Combating ClickJacking With X-Frame-Options
>     EricLaw [MSFT]
>     30 Mar 2010 2:42 PM
> <http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx> 
>
>
>
> ..which apparently supersedes the prior nominal documentation..
>
>
> [1] IE8 Security Part VII: ClickJacking Defenses
>     ieblog
>     27 Jan 2009 9:40 PM
> <http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx> 
>
>
>
> ..and which draft-gondrom-frame-options-00 appears to have been based on.
>
>
> As Dave Ross earlier today noted in..
>
>   Re: [websec] FYI: New draft draft-gondrom-frame-options-01
>   http://www.ietf.org/mail-archive/web/websec/current/msg00388.html
>
> ..the -01 spec rev differs from [2] in that it allows for declaring an 
> origin list as a value for the ALLOW-FROM directive.
>
> Also, the header name is declared as "Frame-Options" rather than 
> what's presently implemented and deployed: "X-FRAME-OPTIONS".
>
>
> Why don't we (WebSec) first simply document present X-FRAME-OPTIONS 
> practice and get that more formally nailed down before we begin 
> enhancing/altering it ?
>
> After all, it's apparently implemented in most all major browsers, and 
> (I hear) emitted by a fair number of web applications. Plus, there's 
> always the question of how closely all those implementations today 
> conform to the present de jure specification, especially the "new" 
> ALLOW-FROM directive in [2].
>
> This would be in the same spirit as the RFC6265 "HTTP State 
> Management" (aka Cookies) effort where we (hopefully unambiguously) 
> documented the present implemented and deployed cookie subprotocol.
>
> thanks,
>
> =JeffH
>
>
>
>
>
>
>
>