Cross-Site Scripting (XSS) is a type of vulnerability which is very widespread and allows an attacker to insert malicious code (JavaScript) into your web browser via the use of a vulnerable web application. The attacker can deliver their malicious code in a number of different ways. They can trick you into clicking on a link (Reflected XSS), or wait for you to visit a page which already has the malicious code embedded into it (Stored or Persistent XSS).
That annoying pop-up box with the number 1 in it? That's just a way that some people visually prove that their JavaScript (XSS) has been run. But don't let that lousy pop-up box fool you, there is a lot more to XSS than that!
A hacker may be able to steal your 'cookies' and login to the application as if they were you!
They may be able to redirect you to a malicious web site without you knowing in an attempt to trick you into giving away sensitive information such as your bank details.
They could add fake login pages to the vulnerable application to trick you into giving them your username and password.
They could even use XSS to bypass other security measures which are built into the application and your web browser to protect you.
The possibilities are almost limitless. Take over your webcam? Yep! Listen in on your computer's microphone? Sure!
For advanced attacks see the The Browser Exploitation Framework (BeEF) tool.
The Apache Foundation, the creators and maintainers of one of the most popular web server software on the Internet had their servers compromised by an initial XSS attack.
An XSS attack on the official forum of the popular Linux Operating System, Ubuntu, allowed the attackers to download the usernames, email addresses and passwords for 1.82 million of their users.
XSS attacks typically target the application's users and their local networks; however, as seen in the examples above, when those users are administrative users the application's web servers are also at risk.
XSS vulnerabilities are discovered within Facebook, Yahoo, Google, Twitter and other high profile websites on a daily basis by independent security researchers participating in bug bounties.
Here is a list of other hacks using XSS - https://www.google.com/fusiontables/DataSource?snapid=S1158702BBoVMake sure that your web browser is kept up to date and that it has all of its security features enabled, such as Cross-Site Scripting (XSS) filtering. If your particular browser does not have an XSS filter, like Firefox, then you can download an XSS filter add-on called NoScript.
Be careful about what links you click on. A link may look harmless enough, but may contain malicious XSS payloads.
Log out of web sites when you are finished with them, this makes it harder for hackers to steal your 'cookies'.
Cross-Site Scripting occurs when untrusted input is output to a page without first being sanitised and/or properly encoded.
For example, if a user supplies their username to login and then you display that username without sanitising and/or encoding it, what happens if the username contains HTML characters? The web browser will not be able to tell the difference between the user's username and what is the page's valid HTML. Data (the username) is being mixed with code (the HTML)! This could allow a user to login with a username that contains malicious JavaScript and have it execute in the browser within the context of your web application.
Make sure that you sanitise the username before using it, for example, if users should only have alpha numeric characters in their usernames then enforce this with input sanitisation. Use a whitelist! Compare the username against known goods instead of known bads.
Use the right encoding! If the username is going to be used within HTML, then HTML encode all of the username's characters. This way the browser will know what is meant to be rendered as HTML and what is not. It's not all about HTML encoding though! You must encode for the right output 'context'. See the links below for further information.
Scan your applications for XSS issues. There are many automated web application security scanners which can detect XSS issues in web applications. You could try giving the Open Source OWASP ZAP a go.
Set your session cookies with the HttpOnly flag. This tells the browser that the cookie should not be accessed by JavaScript, helping protect your users from having their sessions stolen.
A HTTP header called Content Security Policy (CSP) can be set by the web server to tell the web browser what and where JavaScript is allowed to be executed from. It uses a whitelist!
Finally, why not install a Web Application Firewall (WAF) such as the Open Source mod_security! A WAF will give your application that extra layer of defence to defend against those attackers but should be used in a defense in depth scenario and not as the only solution as bypasses are found often.
The two types of XSS mentioned on this page (Reflected and Stored) are not the only two! We have only touched upon the subject here. Want to find out more?
The Open Web Application Security Project (OWASP) is a great resource for all things related to the security of web applications. Check out their wiki article on XSS or their XSS Prevention Cheat Sheet. For information on other types of web application vulnerabilities take a look at the OWASP Top 10.
Thanks for reading,
Ryan Dewhurst & Thomas MacKenzie
---
The goals of this page were to keep it simple, use plain english, keep it short and accurate.
This page's design was inspired by http://justinjackson.ca/words.html
---
Greek Translation - thanks to Nikos Laleas
Spanish Translation - thanks to Abraham Aranguren
French Translation - thanks to Lagarde Languages
German Translation - thanks to b00010111 and Christopher Simpson
Italian Translation - thanks to Giovanni Cattani
Norwegian Translation - thanks to Kai Roer
Arabic Translation - thanks to Abdulkarim Zidani
Polish Translation - thanks to @JanZamoysky
Dutch Translation - thanks to @bartblaze
Swedish Translation - thanks to Mathias Karlsson