Cross-site scripting (XSS) is
a common web application flaw that can lead to
a wide variety of attacks. The problem, and ways to eliminate it,
have been known for years, but new instances of XSS crop up regularly in
web applications—live sites as well as packages like content
management systems. Mozilla has taken the lead on a new security policy,
Content Security Policy
(CSP), which provides a way for sites to avoid XSS. It does that by
browser, but does so
in a way that allows sites to opt-in to the new policy.
server. Normally that happens because some kind of user input was not
properly filtered before it was echoed back on a web page. If that user
input—in the form of a comment on an article, for
happily execute it as if it originated with the site. At that point, an
attacker-controlled code is running with the privileges of the browser user
and the origin site.
by Mozilla's security program manager Brandon Sterne, on the Mozilla
Security Blog, CSP changes that model. Instead of treating all content
received in a response as having the same privilege level, CSP allows the
and where it can appear in HTML.
content will be accepted. If that option is used (via an HTTP
X-Content-Security-Policy header or HTML
files from hosts on the list—all other mechanisms for executing
In order to differentiate legitimate content from injected or modified
external file, and 2) served from an explicitly approved host. This means
attributes will be ignored. Only script included via a <script> tag
pointing to a white-listed host will be treated as valid.
This will be an enormous change for sites that want to use CSP, but it is
backward-compatible with older browsers (or those that do not support CSP),
and there are ways to
incrementally approach the implementation. Sterne notes that all sites
should be able to make the switch, and Mozilla intends to provide a
migration guide to help sites convert to CSP. But, it remains to be seen
whether sites will actually use it. Mozilla security lead, Daniel Veditz,
in the bug entry
that tracks CSP implementation:
Funny you should mentions the onclick attribute as that one specifically
is a popular one to abuse. Whether the burden of rewriting your site to the
supported safe subset of HTML is worth it depends on how valuable the contents
of your site are.
Note that we are not eliminating event handlers, just the ability to specify
them inline. AddEventListener() will still work, as will setting the .click
property of a DOM node. This is a little cumbersome, but there are already
sites that do this for some of their content.
CSP is a gamble, it could be that the hurdle will turn out to be too high. But
if we can get authors over that hurdle we can promise them a safer site.
Another interesting feature of CSP is its ability to notify a site when
there is an attempt to violate the policy. This will even benefit users of
browsers that don't support CSP, as XSS holes can be recognized and fixed
more quickly. Sterne is optimistic about the effect of CSP:
The bottom line is that it will be extremely difficult to mount a
successful XSS attack against a site with CSP enabled. All common vectors
for script injection will no longer work and the bar for a successful
attack is placed much, much higher.
The open question is whether site operators are concerned enough about XSS
help with that process, which could lower the bar somewhat, but it is still
a daunting task. One would guess that the other browsers will take a "wait
and see" attitude before deciding whether to implement it. Though the
implementation is progressing, there is no word from Mozilla on when it
might release a browser with CSP either.
Perhaps CSP is too heavy-handed of a solution to the XSS problem, but it is
good to see Mozilla taking a lead in trying to find something that will
alleviate the problem. There are other, similar efforts in the works at
Mozilla including the Origin header to
mitigate cross-site request forgery and clickjacking.
While these web application vulnerabilities are largely understood and
techniques to avoid them are known, they keep cropping up. Finding ways to
make users' browsers more resistant to these kinds of attacks can only help
improve web security.
to post comments)