XSS Tutorial
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 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. In a typical attack the bad actor will leverage the web application to effectively launch a browser based attack back at an end user.
The diagram below shows the flow of an XSS attack. 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 the person who manages the web application.
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
| Type | Description |
|---|---|
| Reflected | Less damaging but more common than stored XSS. These occur when user input is unsanitised and can be displayed on the page. |
| Stored | Also called Persistent XSS. The user input, eg malicious script, is stored on the backend database. |
| DOM | The 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. |
Reflected and Stored XSS are server side injection. DOM XSS is a client/browser side injection issue.
How to prevent XSS
There are a variety of techniques to try to prevent XSS. Below are just a few. It is important to note that preventing XSS is a combination of actions. No one single action will prevent it.
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.
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.