Dynamic websites use scripts like JavaScript, PHP and .NET to improve the user experience. Whenever a web browser gets a <script> directive in an HTML space like a search, login, or comments field, it automatically executes the script. Cross-site scripting (XSS) vulnerabilities arise when an application fails to validate the user’s input, allowing an attacker to inject malicious code into the vulnerable fields.
Unlike web security threats like SQL Injection that attack the web application itself, an XSS exploit puts the application’s users at risk of session hijacking, malicious code injection, data theft, and other automated attacks. XSS is prevented by securing the input handling process and using security tools like web application firewalls (WAFs).
For an XSS attack to work, the attacker often uses social engineering techniques and tricks the victim into visiting a vulnerable web page containing the script/payload. A typical XSS attack looks like this:
The browser responds according to the script and intent of the attacker. For example, it may send the victim’s cookie to the hacker’s server where the attacker can extract the cookie and use it for impersonation.
In 2005 a programmer known as Samy exploited the XSS vulnerability in MySpace’s personal profile web page template. He was able to upload a self-propagating XSS worm in his profile that was automatically executed by any MySpace user who visited his page.
The Samy worm forced the victim’s browser to add Samy as a friend. In addition, the script copied itself into the user’s profile so that any friends visiting their profile would also add Samy as a friend. The Samy worm propagated exponentially, infecting over one million user profiles in less than 24 hours. The website had to be shut down to stop further infections, fix the XSS vulnerability, and clean the affected profiles.
Cross-site scripting vulnerabilities remain one of the major causes of online attacks. Most of the vulnerable areas include search and login pages that return a response or an error message to the browser – as well as comment fields that allow script tags.
Some effective countermeasures include input validation to verify the user’s input meets the expected format, output encoding to instruct the browser to interpret certain characters as data instead of executing them as code, and a content security policy (CSP) to restrict foreign scripts from loading.
