- From: Neil Matatall <neilm@twitter.com>
- Date: Wed, 16 Jul 2014 15:49:23 -0700
- To: John Yeuk Hon Wong <gokoproject@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
> default-src 'self' foo.com; img-src 'self' foo.com bar.com; Actually, once you take into account that an unspecified directive inherits default-src it desugars to: default-src 'self' foo.com; img-src 'self' foo.com bar.com; script-src 'self' foo.com; style-src 'self' foo.com; object-src 'self' foo.com; media-src 'self' foo.com; etc. The reason I don't like this is people will stuff things into default-src, not realizing it has an effect on all sub-directives. I think a default-src of anything but 'self' or 'none' is an anti-pattern. The directives should be listed out as unique values, or at least be limited to 'self'/'none' when they aren't. On Wed, Jul 16, 2014 at 3:43 PM, John Yeuk Hon Wong <gokoproject@gmail.com> wrote: > 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; img-src 'default' bar.com; > > which would desugar into: > > default-src 'self' foo.com; img-src 'self' foo.com bar.com; > > > > 2) Allowing a reference to any top-level rule > > default-src 'self' foo.com; img-src 'default-src' bar.com; style-src > 'img-src' baz.com; > > which would desugar into: > > default-src 'self' foo.com; img-src 'self' foo.com bar.com; style-src 'self' > foo.com bar.com 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:49:50 UTC