Re: CSP versus Content-Type on scripts and stylesheets

>> 2) With a bit less flexibility, the same attack is possible for
>> scripts. Even if we forget about E4X, there is a concern that an
>> user-controlled CSV or text/plain document hosted within a whitelisted
>> origin could be loaded as a script.
>>
>> The original Mozilla spec eventually added a C-T matching requirement
>> to fix that issue, but I think the current draft drops it.
>
> What do you recommend we do here?  We dropped strict Content-Type
> matching because it makes it significantly harder for folks to deploy
> CSP.  I agree that there's some risk here, but there's also a balance
> with deployability.

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 does sound problematic.  Do you have a recommendation for what we
> should do about it?  What MIME types to JSONP endpoints typically use
> (e.g., what fraction use application/json versus text/javascript
> versus something random)?

Unfortunately, from what I can tell, JSONP usually involves
application/x-javascript, text/javascript, and the like. I don't have
an elegant proposal here. There are three ugly ones:

1) Invent a new MIME type for "CSP-includable" scripts, and reject
everything else. Breaks everything.

2) Do not allow inclusion from URLs with query strings. Breaks some
common use cases (e.g. ?nocache=<unix_time> tricks).

3) Allow pages to opt out of origin scoping (which is problematic also
for other reasons), and specify individual subresource URLs. Adds
complexity.

I doubt any of this will fly. If no practical solutions are seen, then
the spec should at the very minimum include an explicit warning that
JSONP interfaces (as well as any scripts that may have undesirable
side effects in the context of the protected application) must occupy
a separate origin. Unfortunately, that requirement will be difficult
to retrofit or enforce in the long haul, and will end up getting
ignored.

/mz

Received on Friday, 3 February 2012 03:06:16 UTC