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

Remove paths from CSP?

From: Mike West <mkwst@google.com>
Date: Wed, 12 Feb 2014 09:28:10 +0100
Message-ID: <CAKXHy=fOWvN0RpvZfBcFVXt+kvex3wOx6iXfA5PdmD7S5Z6pLA@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Cc: Odin Hørthe Omdal <odinho@opera.com>, Adam Barth <w3c@adambarth.com>, Dan Veditz <dveditz@mozilla.com>, Brad Hill <bhill@paypal-inc.com>, Michal Zalewski <lcamtuf@google.com>, Garrett Robinson <grobinson@mozilla.com>
CSP 1.1 allows authors to add path information to source expressions. It's
implemented in both Firefox and Chrome. Generally, it seems like a
reasonable thing to want to limit script to 'mycdn.com/js', as it limits
exposure. I argued for this feature back in 2012, and implemented it in
Chrome. I think I was wrong to do so.

Exposing path information makes it fairly easy to leak data
cross-origin.  I noted this in May last year[1], but [2] and [3] shows that
it's far more practical than I thought at the time.

Are paths valuable enough to live with this leakage vector? I don't think
they are.

I'd suggest dropping paths from 1.1 now, before LC, and removing them from
both Chrome and Firefox's implementation. We might be able to keep paths
for some directives ('form-action' for instance, which might mitigate some
of the concerns in Michal's Postcards), but I'm not sure that complexity is
worthwhile.

CCing some folks from previous discussions. WDYT?

[1]: http://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html
[2]: https://code.google.com/p/chromium/issues/detail?id=313737
[3]:
http://homakov.blogspot.de/2014/01/using-content-security-policy-for-evil.html

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Wednesday, 12 February 2014 08:29:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 12 February 2014 08:29:02 UTC