By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker exploits a vulnerability within a website or web application that the victim visits, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.
Cross Site Scripting attacks fall into three categories: Persistent/Stored XSS, Reflected XSS and DOM-based XSS.
- Persistent XSS attacks: these store malicious script on the web application server. Any user accessing the application becomes vulnerable to the script executing in their browser.
- DOM-based XSS attacks: when no script is injected into a webpage – instead, an existing script’s behavior is changed in unintended ways. Typically the change is accomplished by changing a trusted DOM element.
Client side scripts have complete access to the DOM, and can access or modify any part thereof, including session data, cookies, accessing previous browsing history, and so on. For example, an attacker who succeeds in exploiting XSS vulnerabilities can hijack session data of an authenticated user. This allows an attacker to change a user password, thus gaining access to the victim’s account/system.
XSS attacks can even allow the whole client system to be controlled by an attacker. Malicious scripts can silently redirect client browsers to attacker controlled domains serving malware, such as browser exploit kits.
XSS injection is possible through any part of a request that is not properly sanitized before being incorporated into a subsequent response. Typical targets include:
- URL Parameters
- FORM Parameters (GET and POST parameters)
- HTTP Headers
- HTTP Referrer Objects
XSS Example Attack
The attacker has now injected the code
Preventing Cross-Site Scripting
Preventing cross-site scripting is difficult. There are a few approaches that are widely used:
- Accepting only plain-text input where possible. This is often effective, though there are many cases where users may want to add limited HTML markup to their input – for example, for formatting purposes.
- HTML entity encoding on significant characters – e.g. turning “<” into “& lt;” – is widely recommend and practiced, but may not prevent all scripting attacks.
- Automated tools exist that will search for and remove malicious code that could be displayed to users. While this is the most comprehensive solution, these tools are unlikely to be totally effective against a determined attacker, and can be expensive to install and maintain.
How Barracuda Can Help
The Barracuda Web Application Firewall contains comprehensive rule sets to detect plain or obfuscated XSS attacks in incoming requests. The default security policy prevents all XSS attacks without requiring any additional configuration or changes to web application code.
Barracuda CloudGen Firewalls include an Intrusion Detection and Prevention System which greatly enhances network security. By reinforcing comprehensive CloudGen network protection, this system helps prevent attacks such as Cross-Site Scripting and buffer overflows.