Re: CSP versus Content-Type on scripts and stylesheets

On Thu, Feb 2, 2012 at 7:05 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>>> 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 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.

>> 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.

That's basically undeployable.

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

That's a pretty ugly layering violation.  :(

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

IMHO, this is the closest to something workable.  Rather than
specifying individual resources, though, someone else proposed that we
let authors restrict scripts to a given directory (which can be
audited more carefully for these sorts of holes).

> 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.

I'll certainly add that to the spec.

Thanks,
Adam

Received on Friday, 3 February 2012 09:09:03 UTC