- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Fri, 14 Feb 2014 09:33:37 -0800
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Many of you have complained that we don't allow <meta>-specified security policies if there is already a header-specified policy, and about the restriction on multiple meta-specified policies. Certainly there are cases where allowing a meta policy to refine a more general site policy would be useful if we can do so without enabling new attacks via the very mechanism we're building. I propose an 'allow-meta;' directive. When specified in header policies (would have to be in all policies if there are multiple headers) this would signal the browser that a meta-specified policy refinement is expected and is not an injection. The first meta-specified security policy would then be enforced. Similarly, as long as meta-specified policies contain the "allow-meta" directive the UA could expect and process additional policies in the document. Taking a stab at updating the steps in "3.1.3 HTML meta Element": Content security policy (http-equiv="content-security-policy") 1. If the user agent is already enforcing a policy for the document and the 'allow-meta' flag has not been set, abort these steps. ... And for language for the directive itself: 3.2.5.? allow-meta The allow-meta directive enables the processing of an additional policy specified through a <meta> element. The syntax for the name and value of the directive are described by the following ABNF grammar: directive-name = "allow-meta" When the allow-meta directive is encountered the user agent MUST set the allow-meta flag which governs whether subsequent <meta> elements containing security policies will be processed. I chose "allow-meta" because it generally matches our whitelisting approach. It is easy enough to add if you need multiple meta-specified policies but by default authors who don't think about it can't have their pages damaged by unexpected injected <meta> elements. However, since most of you don't seem worried about that I could also live with flipping the sense and having a "no-meta-policy" directive instead. That way paranoid folks like myself could protect against injected meta policies (if we remember to do so). -Dan Veditz
Received on Friday, 14 February 2014 17:34:09 UTC