XSS Attack on EJS Pages Prevented on All Browsers but Firefox

Question

I'm testing out XSS on browsers using this very simple test case:

1. The page is run on Express + EJS
2. On routes/index.js, I set the below to get the keyword query string value:

app.get('/search', function(req, res) { res.render('../views/pages/index', { title: req.query.keyword }); });

3. The index.ejs page then takes the title variable and renders it as such: <h1><%- title %></h1> (Note that I did not escape the title variable.)
4. When I copy the following URL (http://localhost:3001/search?keyword=%3Cimg%20src%3D%22private%2Fdist%2Flogo.png%22%20onerror%3D%22window.location%3D%27http%3A%2F%2Fgoogle.com%27%22%20%2F%3E), interestingly every browser I tested (Chrome, Opera, Safari, IE8) but Firefox gives a warning saying they refuse to execute the script.

So I guess the question is, if the developer accidentally fails to escape the string like in this case, and all the browsers but Firefox catch this, then Firefox has a problem with performing the XSS auditing? Am I right to assume this?

Also, am I right to assume that as developers, we should always escape values passed from either the URL or the server?

Thanks in advance for your advice, and pardon me if I'm asking silly questions - just started learning about this XSS thing.

Answer 1

Of course it's not a silly question, it's a very valid one. Let me try to sort a few things out.

The solution to XSS is output encoding. That means encoding special characters when writing variables to the page according to the context they get written to. For an html context (text between html tags, or even tag attribute values between quotes) it is html encoding, but for a Javascript context (when writing variables between script tags in html, or in event attributes like onclick), it must be Javascript (string) encoding.

Nothing but proper output encoding of all variables will prevent XSS in the general case (sidenote: static and trusted content does not have to be encoded, but this level of detail would not fit in an answer here).

Having said that, there are other protections, depending on what environment you use, that may help in some specific scenarios. You should not rely solely on these however, but they are good for additional lines of defenses.

One such defense is built into browsers. If a browser detects that in a query, one of the parameters was Javascript, and then the same Javascript is reflected in the resulting page, some browser will not actually run that, because it is an obvious form of reflected XSS. This behavior is controlled by the X-XSS-Protection response header, in recent browsers you can turn it on or off. The problem is that it is not enough by far. For example it is only effective against reflected XSS, when Javascript from the request is reflected right back in the response. It can be stored in a database upon input and written into different application responses (stored XSS), in which case the protection is useless. Also many attack vectors ("ways of exploiting XSS") are not discovered by browser protections, especially when input is written into a Javascript context. Be aware that as this protection is a browser feature, it is browser specific, different browsers may behave differently.

Also note that there may be other protections in place, like for example .NET imposes request validation to try to filter malicious input and also automatic output encoding for an html context, but not even these together with browser protections are enough to prevent XSS. As said above, XSS is an output encoding issue, nothing else can prevent it (except maybe in some special cases). And then I haven't even mentioned DOM XSS, which is a whole different class of similar problems, but in this answer I wanted to focus on protections built into the browser and the context where that operates.