Re: CSP versus Content-Type on scripts and stylesheets

On Thu, Feb 2, 2012 at 2:41 PM, Adam Barth <w3c@adambarth.com> wrote:

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


Yes, this got implemented in all major browsers including 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
>
>