On 2/3/12 1:08 AM, Adam Barth wrote:
> On Thu, Feb 2, 2012 at 7:05 PM, Michal Zalewski wrote:
>>> We dropped strict Content-Type matching because it makes it
>>> significantly harder for folks to deploy CSP.
>>
>> This seems to be dwarfed by the other constraints of CSP (no
>> inline scripts and stylesheets). There are many sites that do
>> return user-controlled text or CSV documents (definitely
>> several dozen examples on www.google.com), so this seems like a
>> real problem, and I would recommend strict MIME checking.
>
> This difference is that these things are often controlled by
> different folks. Web developers can often re-work their code to
> avoid inline scripts, but MIME types are controlled by server
> operators. That's part of the reason why the platform has been
> moving away from strict MIME types, e.g., for AppCache manifests.
> It's certainly inelegant and unfortunate, but it's the consistent
> feedback we've gotten.
We could do what we've done for inline-scripts: have a hard-line
default policy with an option to disable. Failing that I'd like an
option for sites to opt-in to stricter checking because we've seen
plausible real-world "CSP bypasses" that can't always be blamed on
the site author doing stupid things (E4X doesn't help -- die die die!).
I propose
script-src: 'any-type'
to disable MIME-type checking, otherwise you're limited to a small
whitelist such as application/javascript and application/json, maybe
text/javascript if there's still a lot of that out there.
Defaulting to strict would be safer for site authors who don't have
time to become experts on every technical measure available to them,
but an opt-in 'strict-type' keyword for the script-src directive
would be better than nothing.
-Dan Veditz