RE: ISSUE-25: Do frame-options directives (or other UISafety directives) make sense in a meta tag context? from Fred Andrews on 2012-11-11 (public-webappsec@w3.org from November 2012)

From: Fred Andrews <fredandw@live.com>
Date: Sun, 11 Nov 2012 23:43:34 +0000
To: Web Application Security Working Group <public-webappsec@w3.org>
Message-ID: <BLU002-W61EE26335497BE3B9AE730AA6E0@phx.gbl>

One option is to include such directives as a <html> element attribute, rather than a <meta> element within the head section.  As a html element attribute it is clear than the directive applies to the entire document, just as a HTTP header does, including all the resources than might be referenced while processing the <head> element.  It would appear to remove complexity and should make implementations simpler.  There is a precedent set by the 'manifest' attribute on the html element.

cheers
Fred 

From: fredandw@live.com
To: public-webappsec@w3.org
Subject: RE: ISSUE-25: Do frame-options directives (or other UISafety directives) make sense in a meta tag context?
Date: Sun, 4 Nov 2012 23:54:19 +0000

Some use cases:

1. The document wants the UA to apply restrictions as a defense.

2. The parent may be applying restrictions anyway, but the document wants to communicate compatibility with such restrictions.

Some issues:

1. Would the restrictions be parsed in a first pass of the head element thus applying to all elements of the head, or would the restrictions take effect as they are parsed.

2. Should the directives be loaded only while loading and parsing the meta tag within the head element, or should changes be allowed later.

3. If there is overlap should the effective restrictions be the intersection.

4. meta element versus HTTP header.

This old discussion on CSP HTTP headers versus meta element has some interesting points that may be relevant: http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html

The reason for using a HTTP header for CSP seems to be largely that it would be harder to attack.  A similar argument could be made for other directives.

However some restrictions on when the meta element is parsed and takes effect should close any threats from injected content, and it would seem to be a much lower burden on all the content creation software to use a meta element rather than require a HTTP header, so unless there are some vulnerabilities I suggest the use of a static meta element in the head section.

cheer
Fred

> Date: Thu, 1 Nov 2012 15:56:02 +0000
> To: public-webappsec@w3.org
> From: sysbot+tracker@w3.org
> Subject: ISSUE-25: Do frame-options directives (or other UISafety directives) make sense in a meta tag context?
> 
> ISSUE-25: Do frame-options directives (or other UISafety directives) make sense in a meta tag context?
> 
> http://www.w3.org/2011/webappsec/track/issues/25
> 
> Raised by: 
> On product: 
> 
> 
> 
> 
>

Received on Sunday, 11 November 2012 23:44:01 UTC