Cross-site scripting (XSS) is a security vulnerability allowing a user to alter the code that an application delivers to a user which is executed in the user’s web browser. It is most commonly found in web applications affecting the user's browser, but also possible in other applications with embedded web content, such as an interactive "help" content viewer.
When an XSS vulnerability is used as an attack vector, input sent by the attacker is insecurely processed within the application in a way that allows the attacker to alter the code sent to the victim and executed on in the web browser.
What Types of Attacks Can Happen from XSS?
XSS vulnerabilities may allow for many different possible attacks against the victim. Such attacks may include:
- Stealing the login session token, allowing the attacker to interact with the application as the victim without knowing his password
- Forcing the user to send attacker controlled requests to a server - imagine a vulnerable bank web application forcing you to transfer money
- Changing the content of page - imagine a popular news site altered to declare a fake stock market crash happened inciting panic
- Tricking the victim into divulging her password to the application or other applications
- Infecting the victim with other malicious code using a vulnerability in the web browser itself - possibly taking over the victim's computer
Some attacks can be sent to the application server and executed against many other users of that application, for example:
- A vulnerable forum site or comment system allows a user submitted post to be viewed by many other users that each become victims of the attack
- A vulnerable contact form sends a malicious message to site administrators that gives the attacker access to the "admin panel" when viewed by an administrative user
Other attacks require the attacker to convince or trick the user into first loading a malicious link, possibly using email, IM, or a forum post or comment.
How does a Cross-Site Scripting Attack Work?
To illustrate an example attack, we'll use a simple "Hello world" web application.
The application displays "Hello, World!" by default when visiting the server in a browser:
http://localhost:8080/
The application is interactive, and will greet users when provided a username:
http://localhost:8080/Mike
Unfortunately the application does not properly validate or encode user provided input. This time, in addition to the username, JavaScript is added:
http://localhost:8080/Mike<script>alert("Malicious Code")</script>
The output looks nearly the same, except that the JavaScript is interpreted and executed in the browser.
Keep in mind, a knowledgeable attacker would write exploit code that does not pop up and announce itself.
This is how the application may look once this vulnerability is resolved, such as by encoding the output of the application so that the browser knows that this is data that should not be interpreted as application code:
The difference can be better seen in the HTML source as seen by the browser. All the special characters that can be interpreted as code have been encoded so the HTML representation of each special character is displayed to the user:
How Do I Prevent This From Happening?
To prevent this vulnerability, developers must validate all input to the application and encode all input that is included in output. This is an essential part of application development and will help prevent many different types of vulnerabilities, not just XSS.
