Cross Site Scripting (XSS) Cheat Sheet, Attack Examples & Protection

The XSS vulnerability has been starring regularly in the OWASP Top-10 for years. More and more web applications and websites today are found to be vulnerable to Cross-Site Scripting (XSS) vulnerability. XSS takes advantage of both client and server side programming.

XSS payloads cause the victim’s browser into executing dangerous commands, eventually leading to cookie theft and data manipulation.

 

What is XSS?

XSS attacks are typically planned and executed following way:

 

  • The first step is locating XSS vulnerabilities within web applications. This can be performed with the help of proprietary tools available online.
  • Next, the malicious attacker creates a XSS payload to exploit the vulnerability. Advanced hackers can also disguise the malware with HEX encoding, making it harder to locate and detect.
  • The final stage involves the implementation of social engineering and various phishing techniques to trick users into clicking on the tainted links that initiate the attack sequence.

 

For example, let’s take a look at a trusted interactive website like Amazon. It’s very easy for the attacker to plant malicious code in the product feedback section of the web application. Once the unsuspecting user clicks on the malicious element, his browser executes the URL and causes extensive damage to the compromised computer.

 

What types of XSS attacks exist?

There are four main XSS methodologies in use today:

 

Stored (Persistent) Cross-site Scripting

Also referred to as Type-I XSS, Stored XSS involves the planting of the attack payloads into vulnerable servers. Clicking on a malicious link (URL) planted in a trusted web application initiates the hacking. These URLs are commonly found in various well-known and trusted websites that feature newsgroups, forums, talkback boards and discussion threads.

 

Reflected (Non-Persistent) Cross-site Scripting

The most commonly found XSS, also known as Type-II, occurs when the server reads data directly from the HTTP request and reflects it back in the response. The JavaScript is usually HEX Encoded to disguise the real intent of the attacker.

Web applications that don’t sanitize user input (i.e – URLs) are easy targets for the attackers. The victim’s browser executes the malicious URL as it assumes that it’s coming from a “trusted website”, which in fact is vulnerable to Cross-Site Scripting.

 

Example 1

index.php:
<?php
$user_name = $_GET['name'];
echo "Welcome $user_name<br>";
echo "<a href="http://www.test-attack.com/">
Click for more info</a>";
?>

Now the attacker can craft a URL in the following format and send it to the victim:

http://www.test-attack.com/index.php?name=myuser<script>alert(‘hacked’)</script>
When the victim loads the URL shown above into the browser, he will see an alert box with the text ‘hacked’. Even though this specific example doesn’t cause any damage besides the annoying ‘hacked’ pop-up, it’s clear how an attacker can use this simple and straightforward method to exploit websites and applications.

 

Example 2

Consider a website that has URLs of the following type:

http://www.yoursite.com/index.html?name=Alex

Let us say the parameter “name” is used to define name values for the user. The website uses this value to say “Hello Alex” on the webpage. In this example, a malicious hacker can exploit the parameter “name” by attaching malicious code to the parameter “name”:

http://www.yoursite.com/index.html?name=<script>alert('XSS vulnerability')</script>

This specific shows a message box to the user displaying the words ‘XSS vulnerability’, but in reality, actual malware code could have been loaded via this exploit on a website.

This attack succeeds because the web application that analyzes this URL and the website incorrectly trusts the user to always input safe data. It is not prepared for these threats. In this case, the attacker has used a benign website to launch a malware attack on an unsuspecting user, and the website owner usually has no idea that his or her website was exploited.

 

Client Side / DOM Based XSS

Also known as Type-0 XSS, this XSS methodology basically manipulates the Document Object Model environment in the victim’s browser. Once infected by the XSS payload, which can simply modify a JavaScript element, one or more DOM features are compromised and are manipulated by the hacker.

For example, the following code has been written to create a form that enables the user to pick his preferred language. There is also a provision for a default language in the query string, appearing as the parameter “default”.

 

Select your language:

<select><script>
 document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
 document.write("<OPTION value=2>English</OPTION>");
 </script></select>

Assuming a web page is invoked with a URL such as:

http://www.some.site/page.html?default=French

 

A DOM Based XSS attack against this page can be launched by sending this URL to a victim:

http://www.some.site/page.html?default=<script>// <![CDATA[
alert(document.cookie)
// ]]<</script>

 

When the URL is clicked, the browser sends a request for:

/page.html?default=<script<alert(document.cookie)</script>

 

The server responds with the page containing the JavaScript code. The browser creates a DOM object for the page, in which the “document.location” object contains the string:

http://www.some.site/page.html?default=<script>// <![CDATA[
alert(document.cookie)
// ]]></script>

 

The original JavaScript code in the page does not expect the default parameter to contain HTML markup and it is echoed into the page DOM at runtime. The browser then executes the malicious script after rendering the resulting page.

alert(document.cookie)

The attack manifests itself at the client-side script at runtime after the flawed script accesses the DOM variable document.location and assumes it’s not malicious.

 

POST Method XSS

These attacks use HTTP POST variables, which are not sent along with the URL. These XSS attacks require the creation of a go-between payload page where the victim is re-directed after clicking on the malicious link. The victim’s browser then is manipulated by the jump-code into sending the malicious POST request to the vulnerable application.

 

What are the dangers of XSS?

XSS attacks can cause various levels of damage to web applications. This depends on the type of script delivered by the hackers. The most commonly found after-effects of XSS involve:

 

  • Identity theft
  • Session hijacking
  • Social engineering
  • Harvesting sensitive information saved in JavaScript variables
  • Re-directing traffic by altering URLs
  • Recording of keystrokes and input for commercial or criminal purposes
  • Fetching GPS/Camera data if the access has been granted by the website
  • Launching attacks on systems connected to the exploited computer
  • Probing and sniffing entire networks where the victim is located

 

How to prevent XSS attacks?

The following steps can be taken to steer clear of XSS threats:

 

  • 1. Never insert untrusted data except in allowed locations.
  • 2. HTML escape before inserting data into HTML element content.
  • 3. Attribute escape before inserting untrusted data into HTML common attributes.
  • 4. JavaScript escape before inserting untrusted data into JavaScript data values.
  • 5. CSS escape and strictly validate before inserting untrusted data into HTML style property values (while trying to insert untrusted data into stylesheets or style tags).
  • 6. URL escape before inserting untrusted data into HTML URL parameter values.
  • 7. Sanitize HTML markup with a library designed for the job (HTML Sanitizer).
  • 8. Prevent DOM-based XSS vulnerabilities (Click for the OWASP cheat sheet).

To access the entire OWASP Cheat Sheet – Click Here

 

Preventing XSS attacks with CxSAST

The Checkmarx static code analysis solution basically searches for data flows (user input) that gets outputted to the browser without being properly validated or sanitized. Once these are located, all the developer has to do is to take care of the vulnerable LOCs that are pinpointed by CxSAST.

 

Back to Vulnerability Knowledge Base

REQUEST A DEMO

Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.

Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.