- From: John Wilander <john.wilander@owasp.org>
- Date: Thu, 3 May 2012 11:20:36 +0200
- To: Michal Zalewski <lcamtuf@coredump.cx>
- Cc: Tanvi Vyas <tanvi@mozilla.com>, public-webappsec@w3.org
- Message-ID: <CALrECXCkb0q-bV6oNsJMeEz4DiOab9+KZaO3NgaZ6Fktzhcy4w@mail.gmail.com>
Meta tag support in head only is fine by me, especially if we can consider meta tags in body in subsequent CSP versions. I'd like to go deeper into why headers might be even *less* secure than meta tags or document.enforceSecurityPolicy(). 1. *CSP headers might be stripped*. Google went though a lot of work getting SDPY to work on the heterogeneous Internet. They found that https was the only way to get away from the hotchpotch of proxies, filters, firewalls, IPSs etc that manipulate HTTP requests between web servers and end users. This means CSP headers run a tangible risk of being stripped before they reach the user they're intended to protect. I've checked with large organizations where I know the OPs and yes, they will strip CSP headers by default. Meta tags or document.enforceSecurityPolicy() on the other hand have a much better chance of surviving. Header stripping is mostly an http issue but with ssl terminating proxies it affects https too. Organizations who deploy CSP will have to use the reporting feature to find out about this problem. And when they do they will have close to zero things to do about it. 2. *Cached web pages might not mean cached CSP headers*. A colleague of mine has been trying to find convincing evidence that CSP headers will be cached for web pages that are served from a cache without an http 304 request. Also, he's not sure server-side caching solutions will preserve CSP headers and include them in 304 headers. On the contrary, meta tags or document.enforceSecurityPolicy() will be cached along with the page content. If any of you have information on (custom) header caching we'd be happy to hear about it. If this is an issue we might need to add caching behavior to the CSP spec. Regards, John 2012/5/2 Michal Zalewski <lcamtuf@coredump.cx> > > document.enforceSecurityPolicy("default-src 'self' "); > > Also note that given the behavior of certain XSS filters that make it > possible to selectively disable some of the <script> blocks (but not > others), this seems undesirable. > > Frankly, I don't see any truly compelling reasons for dropping <meta>; > CSP is far from being perfect, and has several far more concerning > bypass vectors; but it's better than nothing. Making it harder to > deploy it in a common use case just to prevent an attack in a far more > peripheral one (which can be readily turned into XSS in some browsers > anyway) seems odd. > > /mz > > -- 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 Thursday, 3 May 2012 09:21:11 UTC