Re: CSP versus Content-Type on scripts and stylesheets

On Mon, Dec 19, 2011 at 11:55 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
> The origin scoping of CSP rules for scripts and stylesheets poses a
> bit of a challenge when dealing with resources that are not meant to
> be interpreted as CSS or JS, but will parse as such. I don't see this
> being addressed consistently in the current spec, but it's probably
> worth giving some thought soon.
>
> There are at least three cases worth singling out:
>
> 1) In principle, any HTML 404 page that echoes back the requested URL
> may be interpreted as CSS, because of the preposterously lax parsing
> and resynchronization rules for stylesheets. If I can include:
>
> <link rel=stylesheet
> href="http://permitted-source/nonexistent/}.foo{color:pink;}">
>
> ...then the parser will happily skip any trailing HTML, resynchronize
> from the initial }, and I just scored an injected ruleset.
>
> Note that this is mitigated in Chrome and Firefox due to the
> improvements proposed by Chris Evans to address an unrelated problem
> of cross-domain data theft, but CSP should probably not implicitly
> depend on his proposed approach.

Yeah, we should require this explicitly.  This got implemented in IE
and Safari as well (not sure about Opera).  That mean's we're in
pretty good shape.  I've added some text to the security
considerations section discussing this topic:

http://dvcs.w3.org/hg/content-security-policy/rev/52277a98cf90

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

> 3) Possibly the worst case: if any of the permissible script origins
> has any JSONP interface within its bounds, then even with C-T
> matching, CSP effectively permits return-oriented programming by
> loading scripts such as:
>
> http://permitted-source/some_jsonp_api.php?callback=do_something
> http://permitted-source/some_jsonp_api.php?callback=do_something_else
>
> Worse yet, JSONP interfaces seldom sanitize callback parameters with
> particular zeal, which normally doesn't cause major problems. In
> absence of robust sanitization, we can do this:
>
> http://permitted-source/some_jsonp_api.php?callback=do_something(123)
> http://permitted-source/some_jsonp_api.php?callback=something=123||

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)?

Adam

Received on Thursday, 2 February 2012 22:42:06 UTC