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

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

/mz

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