W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2014

Re: [CSP] Rule referencing

From: John Yeuk Hon Wong <gokoproject@gmail.com>
Date: Wed, 16 Jul 2014 18:43:11 -0400
Message-ID: <53C6FFFF.1090502@gmail.com>
To: public-webappsec@w3.org
I like the idea of union, but is it the responsibility of the browser to 
implement and understand the union?
Say I am writing a Django website. I probably won't write the policy by 
hand. Instead I might reply on the Django CSP to provide an interface 
(most likely an UI) which will allow me to create groups such as 
default-src, img-src.. In that UI I should be able to say "union group A 
and group B". The middleware (django-csp or alike) should output the 
full header in the response.

If you are writing the header by hand it is indeed tedious to repeat 
yourself, but that's the job of a tool. As for browser implementation - 
I think it's up to the implementation to consider a more efficient 
algorithm and data structure to not store the same foo.com 100 times, 
but I don't think that's what you are proposing.

Correct me if I am wrong.

John
On 7/16/14 6:20 PM, Alex Sexton wrote:
> Hi all!
>
> I often find that my CSP rules in more complex apps often get very 
> large, but also very repetitive. I think there is probably some sugar 
> that could dramatically reduce the size and mental overhead of writing 
> the rules. (But I also understand that shipping quickly, without sugar 
> is the right initial path).
>
> So for your future consideration, I'd like to propose some way of 
> aliasing, or referencing rules (or just one rule). A few ideas:
>
>
> 1) Adding the 'default' rule, that points at 'default-src'
>
> default-src 'self' foo.com <http://foo.com>; img-src 'default' bar.com 
> <http://bar.com>;
>
> which would desugar into:
>
> default-src 'self' foo.com <http://foo.com>; img-src 'self' foo.com 
> <http://foo.com> bar.com <http://bar.com>;
>
>
>
> 2) Allowing a reference to any top-level rule
>
> default-src 'self' foo.com <http://foo.com>; img-src 'default-src' 
> bar.com <http://bar.com>; style-src 'img-src' baz.com <http://baz.com>;
>
> which would desugar into:
>
> default-src 'self' foo.com <http://foo.com>; img-src 'self' foo.com 
> <http://foo.com> bar.com <http://bar.com>; style-src 'self' foo.com 
> <http://foo.com> bar.com <http://bar.com> baz.com <http://baz.com>;
>
>
> 3) Allowing variables
>
> (I don't actually like this idea enough to type it all out, but you 
> could have `--common-src` and reference it, much like css intends on 
> doing in the future)
>
>
> --
>
> The only problem this would cause, in my experience (but I am by no 
> means a comprehensive test), would be that I often want to take the 
> common case, and *remove* one rule. These solutions are mostly 
> additive in nature.
>
> I also understand that the savings don't seem very impressive with 
> these 1-tiny-domain example urls. In practice, I have many more, much 
> longer, fully qualified paths and domains and protocols. It would 
> absolutely cut down the total size of the header (by far my biggest), 
> as well as allow me to make changes to the rules more easily (though I 
> more or less wrote a transpiler that does this, so it'd be more for 
> other future users :D).
>
>
> Thanks for your eyes/ears!
>
> -- 
> Alex Sexton
Received on Wednesday, 16 July 2014 22:43:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC