W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2011

CSP versus Content-Type on scripts and stylesheets

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Mon, 19 Dec 2011 23:55:11 -0800
Message-ID: <CALx_OUDD400cshOGRcoWCVCqMh98dSrugSSuRKDrbAis+zx0Zw@mail.gmail.com>
To: public-webappsec@w3.org
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.

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.

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

/mz
Received on Tuesday, 20 December 2011 07:56:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 20 December 2011 07:56:00 GMT