W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: [Content Security Policy] Proposal to move the debate forward

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Mon, 31 Jan 2011 02:10:33 -0800
Message-ID: <AANLkTimZPOkRWBV0Cn9foio=EwZWPJPshMzEGK8-jjtA@mail.gmail.com>
To: Gervase Markham <gerv@mozilla.org>
Cc: Brandon Sterne <bsterne@mozilla.com>, gaz Heyes <gazheyes@gmail.com>, public-web-security@w3.org
> Question is: is a script-key-based approach therefore infeasible because
> no-one will adopt it because it makes caching impossible?

Caching on client-side would not be a big deal - re-using a cached
page is also reusing any injected content, which the attacker can't
retrospectively modify without a new request; DOM XSS is outside the
scope of all defenses discussed here.

Caching on shared proxies is more of an issue, true. While sites that
return cookie-authenticated data are usually already in trouble if
this happens (and a good number of top sites on the Internet use
blanket no-cache / no-store / max-age=0 or at least "private") - and
sites that do not use authentication are usually much less of a risk
for XSS - it's probably dangerous to delegate the responsibility to
use specific caching directives in conjunction with script tokens to
site owners.

A simple tweak that works around this problem is to have the browser
challenge the server with a random token in every HTTP request; if the
server is policy-enabled, it may opt to return that token in the
response for inline scripts. This has a side effect of also
eliminating the requirement for hundreds of oddball web frameworks to
come up with good random numbers on their own - doing this well across
a couple of web browsers is easier.

A way that does not require a new header may ask the server to use
SHA1 of user request and a server-generated salt, instead; the browser
can then compare the token against the values used to make the
request, and accept inline scripts if there is a match. This offers
reasonable protection for all common cases.

A more trivial option is to simply reject inline scripts with tokens
if no explicit "private" / "no-cache" directives are found, alerting
site owner to the problem immediately.

Received on Monday, 31 January 2011 10:11:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:18 UTC