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:
- 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.
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
";* *echo "* *Click for more info";* *?>
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:
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:
- Identity theft
- Session hijacking
- Social engineering
- 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
The following steps can be taken to steer clear of XSS threats:
- Never insert untrusted data except in allowed locations.
- HTML escape before inserting data into HTML element content.
- Attribute escape before inserting untrusted data into HTML common attributes.
- 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).
- URL escape before inserting untrusted data into HTML URL parameter values.
- Sanitize HTML markup with a library designed for the job (HTML Sanitizer).
- Prevent DOM-based XSS vulnerabilities (Click for the OWASP cheat sheet).
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.