- From: John Wilander <john.wilander@owasp.org>
- Date: Fri, 27 Apr 2012 11:18:12 +0200
- To: public-webappsec@w3.org
- Message-ID: <CALrECXCkR9ndM+JWzxSzowA2BYagfwyMWKDdhC-HbHWQL3PXAA@mail.gmail.com>
Hi Public WebAppSec! I've been reading through the discussion on meta tag support in CSP 1.0 (thanks Brad for the links). Here are my arguments for bringing support for CSP in meta tags back into 1.0: 1. *Ease of adoption over "perfect" security*. The future holds numerous attack vectors, some of which will probably take a stab at CSP. But we have a massive XSS problem at hand and we need to deal with it. Imagine the "mass vaccination" effect of telling developers of the world that if you already have your JavaScript on file and host it locally you can just paste this <meta http-equiv="Content-Security-Policy" content="default-src 'self'" /> and you're basically done with cross-site scripting. I've been down the road if hair splitting security discussions so many times and it very rarely helps security in practice. Let's not allow the fear of header injection to cripple ease of adoption. 2. *Adding response headers may be hard or impossible*. The long tail of web apps out there are hosted on shared platforms where it's hard, perhaps impossible, to add new response headers. We might argue that web apps outside Alexa 500 are not important but I'd say they are. We need mass adoption and mass awareness to do something about XSS. The lone web developer who pastes a CSP meta tag in his/her personal web app today may be an internet bank developer next year. 3. *Frontend-only web apps don't deal with http headers*. The drive around HTML5, CSS3 and JavaScript is producing more and more frontend-only web apps. People who write those are super familiar with a clean DOM and engineering practices such as keeping JavaScript in files. Such developers could serve as a spring board for CSP. But they rarely care for web servers. Their static files just need to reach their users. 4. *Enterprise http infrastructure is typically a mess*. Adding a http response header may be easy for projects or organizations where developers have full access to the web servers, the web app has its own server, and not too much happens on the way out of the corporate network. But in the enterprise world you rarely find such situations. Instead there's a plethora of outgoing filters and proxies who fiddle with http requests and responses. Also the web app you're willing to try out CSP for will have to live alongside a hundred other web apps so the response header has to be properly scoped to the right context root. Imagine getting that right in the testing environment, acceptance testing environment, and finally into production. That might be months of work. On the contrary, adding a meta tag is a piece of cake and is automatically scoped. Do we really believe developers or security departments will invest months of work to just try out CSP? Pretty please, with sugar on top, can we reconsider CSP meta tags? :) Regards, John -- John Wilander, https://twitter.com/johnwilander Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com Conf Comm, http://www.owasp.org/index.php/Global_Conferences_Committee My music http://www.johnwilander.com & my résumé http://johnwilander.se
Received on Friday, 27 April 2012 09:21:25 UTC