In annals of useless of advice, this answer from the Cross Site Scripting (XSS) FAQ on PHP Advisory, to the question of what end-users can do to protect themselves, must rank pretty high:
The easiest way to protect yourself as a user is to only follow links from the main website you wish to view. If you visit one website and it links to CNN for example, instead of clicking on it visit CNN’s main site and use its search engine to find the content.
How is a typical user supposed to take this? “Gee thanks! All I have to do to protect myself is stop using hyperlinks to get from place to place on the Web!”
Despite the tendency of commercial PCI certification programs like Hacker Safe to underplay XSS vulnerabilities, the market will surely find a way, over time, to punish sites (especially e-commerce sites) that let the burden of worrying about XSS vulnerabilities fall on the user. And this in turn means that developers will more and more be expected to make their sites XSS safe “out of the box”. With that in mind, maybe now is a good time for a review of XSS fundamentals, as well as a look ahead to how the good guys are fairing in the battle between exploits and counter-measures.
Let’s start first with the casual definition from us:
The problem with this definition is that it is somewhat operational and certainly not general enough to cover all the possible ways XSS may be used. However, if you get the gist of XSS from that definition the authoritative definition (circa 2002) of the issue makes a bit more sense:
The problem is two-fold:
- Trusting input from an external, untrusted entity, such as a user
- Displaying said input as output
This is bad because a malicious user could access another’s important data, such as their cookies.
That’s not a bad definition, as far as it goes. It comfortably fits the standard XSS scenarios, such as this one:
- An email containing a link to that page is sent to the victim.
- The victim clicks on the link and goes to the compromised site.
A more fundamental definition, which also fits this common scenario, might be something like this: XSS describes a class of unwanted HTTP side-effects that are possible because of the untyped nature of HTTP. We’ll see next week why this might be a better model of XSS going forward. In the meantime, Howard’s definition of the problem is certainly enough to get us thinking comprehensively about counter-measures, which is good. And for the particular variety of XSS exploit he highlights, a standard, easy-to-implement solution is emerging: HTTP-only cookies.
<div id="responseOutput" class="response"></div>
How do HTTP-only cookies combat this? When setting an HTTP-only cookie, this is what it will look like to the browser, at the HTTP level:
<br></br> Set-Cookie: HttpOnlyCookie=MyUserName; path=/; domain=mysite.com; HttpOnly<br></br>
HTTP-only cookies are an important advance, in part because they are a quick-and-easy way to protect a major target of XSS attacks. That being said, it’s important to keep in mind that XSS doesn’t always rely on getting at the user’s cookie. HTTP-only cookies are useful but fundamentally reactive–they close off one way of exploiting the fact that unauthorized code has gotten onto a site and from there onto a user’s browser, but they don’t stop that code from getting where it shouldn’t be. The core problem remains one of greater control over HTTP input and output.
Next week we’ll take a look at more fundamental XSS counter-measures — and also at the next generation of XSS attacks.