Issue¶

What exactly is cross-site scripting (XSS), and how can I identify it?

Resolution¶

Cross-site scripting (XSS) is a class of code vulnerabilities that allows code to be executed inside your browser without your consent or knowledge. XSS exploits are commonly performed with JavaScript, but Flash, Java, and other similar web programming technologies have been used.

XSS relies on the ability of code in your browser to interact with a site on your behalf using your session (cookies) so that it has the same access that you do. If you visit a page with malicious XSS code running, it can do any action on the site that you can, including posting new content, becoming "friends" with other users on the site, voting in polls, and changing administrative settings on the site.

Why is it called "cross-site scripting?"¶

From his post on the history of cross-site scripting , Jeremiah Grossman describes the original version of XSS:

A malicious website could load another website into an adjacent frame or window, and then use JavaScript to read into it. One website could cross a boundary and script into another page, pull data from forms, rewrite the page, etc. Hence we get the name cross-site scripting.

At that time, XSS was about malicious code on one site affecting another site, but now it describes general "HTML code injection" where some form of code (not necessarily JavaScript) is injected into the page in a way that the browser is tricked into treating it as executable code rather than data.

How does cross-site scripting work?¶

A poorly configured site can allow a malicious visitor to use XSS to change a user's password . You can use the Security Review module to identify and fix some XSS vulnerabilities in a site. The Security Review module is not a complete solution; it only finds some common vulnerabilities. This module is only available for Drupal 7, and is currently being ported over to Drupal 8.

How do I identify cross-site scripting?¶

Next, let's look at some ways to identify a cross-site scripting vulnerability. The basic problem is being able to execute code inside the browser. Security reviews often look for JavaScript vulnerabilities, though you shouldn't ignore other avenues for attacks. Experience has uncovered three tricks to make research more efficient:

• Use something that is difficult to miss, such as a JavaScript alert() box that pops up.
• Make the content of the alert specific to the place where the injection was made so you can trace it back.
• Try multiple methods, because some fields will filter some types of information, but not others.

Specifically, try to inject these two strings:

• copy

  "><script>alert('blog-node-title');</script>

• copy

  "><img src="u.png" onerror="alert('blog-node-title');"</script>

By starting with ">, we can more reliably break out if the code is being placed into an HTML attribute. If you post these strings into information and then browse around the site, you may see a JavaScript pop-up box. You can look at the message in the alert (for example, blog-node-title in the preceding examples) and see that it is coming from the title field of a blog node. You should then look into the HTML of the page, find the place that the JavaScript is leaking through, and trace back through the code to add an appropriate filter function.