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

Re: An urge for CSP META tag in 1.0

From: John Wilander <john.wilander@owasp.org>
Date: Thu, 3 May 2012 11:20:36 +0200
Message-ID: <CALrECXCkb0q-bV6oNsJMeEz4DiOab9+KZaO3NgaZ6Fktzhcy4w@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: Tanvi Vyas <tanvi@mozilla.com>, public-webappsec@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 3 May 2012 09:21:12 GMT