W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2012

An urge for CSP META tag in 1.0

From: John Wilander <john.wilander@owasp.org>
Date: Fri, 27 Apr 2012 11:18:12 +0200
Message-ID: <CALrECXCkR9ndM+JWzxSzowA2BYagfwyMWKDdhC-HbHWQL3PXAA@mail.gmail.com>
To: public-webappsec@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 09:21:26 GMT