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

From: =JeffH <[email-masked]>
Date: Thu, 07 Jul 2011 21:38:35 -0700

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

---

From: David Ross <[email-masked]>
Date: Fri, 8 Jul 2011 17:00:16 +0000

I agree it would be good to get the ALLOW-FROM in the draft consistent with [2].  The major difference does seem to be the fact that the RFC supports a list of origins for ALLOW-FROM, whereas [2] does not.

> presently implemented and deployed: "X-FRAME-OPTIONS".

Since the RFC will standardize it, I think it may be appropriate to drop the X- prefix.  But then also we should probably have the RFC draft explicitly specify the behavior if there are multiple conflicting X-FRAME-OPTIONS / FRAME-OPTIONS headers present in a given HTTP response.  (Eg: What happens if there is both an X-FRAME-OPTIONS and a FRAME-OPTIONS header, each with ALLOW-FROM directives pointing to different sites?) 

David Ross
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Thursday, July 07, 2011 9:39 PM
To: Tobias Gondrom
Cc: IETF WebSec WG
Subject: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

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..

thanks,

=JeffH

_______________________________________________
websec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/websec

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 23 Jul 2011 17:19:06 +0100

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

- Tobias

On 08/07/11 05:38, =JeffH wrote:
> It appears that the -01 rev of draft-gondrom-frame-options takes into 
> account the apparently present X-Frame-Options documentation here..
>
>
> ..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
>
>
>
>
>
>
>
>