In this Cross-site scripting (XSS) tutorial, the basics of cross site scripting and the damage that can done from an XSS attack are explained.

Many people treat an XSS vulnerability as a low to medium risk vulnerability, when in reality it is a damaging attack that can lead to your users being compromised. XSS continues to be in the OWASP Top 10 Web Application Security Risks. Some find SQL Injection a more easily understood vulnerability, as it involves attacking a web application to extract data or modify the web apps back-end database.

An XSS attack involves compromising the user's browser rather than the actual web application. Keep in mind that the web application is still involved as it is where the attack will originate. So in a typical attack; the bad guy will leverage the web application to effectively launch a browser based attack back at an end user.

Attacker -> exploits web application -> web application delivers a malicious script to a normal users browser -> attacker now can control the user's browser. This is bad for the user and bad for you if you manage the web application.

diagram representing the basics of an xss attack

Examples of the damage an XSS attack can cause:

  • Phishing : Redirect page to phishing sites, or fake login pages
  • Cookies : Steal the users cookies, allowing them access to other web applications with authenticated sessions
  • Insert links to remotely hosted client side exploits within a html body; with the goal of installing malware on the system (key loggers, remote access tools)

These are the most common and dangerous attack outcomes, which typically lead to complete compromise of a users system or personal information.

How does XSS work?

The actual xss attack is formed by injecting unsanitised input into a web application. The input is usually in the form of javascript, that can be stored by the application and returned to other users when they visit the page. Thereby executing the javascript in the users browser.

There are different types of XSS attack and different exploitation points but this is a typical and easy to understand scenario.

Three main types

TypeDescription
ReflectedLess damaging but more common than stored XSS. These occur when user input is unsanitised and can be displayed on the page.
StoredAlso called Persistent XSS. The user input, eg malicious script, is stored on the backend database.
DOMThe rarest of the XSS but can have serious repercussions. Processes data from an untrusted source. The malicious payload alters the DOM in the victims browser.

How to prevent XSS

Sanitize input

Sanitize the input, all user submitted input anywhere in an application must be treated as hostile and filtered. This should be done by the application code, but can also be performed by a web application firewall (WAF) such as mod_security. The most effective way to prevent this is to do both, use well coded applications and have a WAF or filtering as a second line of defense.

HTTP Headers

In addition, the HTTP response header Content-Security-Policy can be used to control features in a users browser to guard against XSS.

There is a HTTP Header that can be used to provide protection for legacy browsers that do no support CSP. This is the X-XSS-Protection HTTP Header.

Knowledge

Keep in mind that the malicious input could be executed from not only script tags but also the body tag, image tags and more. A browser can be quite forgiving even if the resulting html is broken, it still may execute the script.

While applying the tools above can help mitigate some XSS, it is worth noting they won't mitigate everything. Be vigilant and rigorous in testing and reviewing your site and code.

Conclusion

This tutorial is aimed at those who need a basic understanding of cross site scripting. For further information, take a look at the resources available on the OWASP web site.