Introduction to Cross Site Scripting (XSS) and Drupal

This article provides an introduction to Cross Site Scripting in Drupal.

Cross Site Scripting is a class of vulnerabilities that allows code to be executed inside your browser. It is commonly exploited with Javascript, but could also be exploited with Flash, Java, or other similar web programming technologies. XSS relies on the ability of code in your browser to interact with a site on your behalf using your session (cookies) so it has all the same access that you do. If you visit a page with malicious XSS code running, it can do any action on the site you can: post new content, become "friends" with other users on the site, vote in a poll, change administrative settings on the site, etc.

Basics of How Cross Site Scripting Works

This video shows an example of a poorly configured site where a malicious visitor can use XSS to change a user's password. It then shows how to use the Security Review module to identify and fix some XSS vulnerabilities in a site. Note that the Security Review module is not a complete solution, it only finds some common vulnerabilities.

.

Identifying 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 some code inside the browser. We tend to look for Javascript vulnerabilities, though you shouldn't ignore other avenues for attacks. Years of looking for XSS has shown two tricks to make your research more efficient:

1. Use something hard to miss, like a Javascript alert() box that pops up.
2. Have the content of the alert specific to the place where the injection was made so you can trace it back
3. Some fields will filter some information, but not others, so try multiple methods

Specifically, try to inject these two strings:

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

By starting with "> we can more reliably break out if the code is being place into an HTML attribute. If you post these 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 (e.g. blog-node-title in the above 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 Javascript is leaking through, and trace back through to code to add an appropriate filter function.

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, then use JavaScript to read into it. One website could cross a boundry and script into another page. Pull data from forms, re-write the page, etc. Hence the name cross-site scripting (CSS).

At that time it's clear that this 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.

Future XSS articles will cover:

• What are the appropriate filter functions to use? How do I decide when to use them?
• What are some other examples of cross-site scripting?

Read more about XSS