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.
XSS attacks are typically planned and executed following way:
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.
There are four main XSS methodologies in use today:
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.
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.
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:
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.
Consider a website that has URLs of the following type:
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”:
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.
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:
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:
http://www.some.site/page.html?default=<script>// <![CDATA[ alert(document.cookie) // ]]></script>
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.
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.
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:
The following steps can be taken to steer clear of XSS threats:
To access the entire OWASP Cheat Sheet – Click Here
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.
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.