Testing cross-site scripting (XSS)

We have heard about cross-site scripting (XSS) attacks on major websites and also that a majority of websites are open to XSS attacks. How can we test for XSS vulnerabilities in our own web application? 

 First, let us understand XSS. It involves injecting scripts into the web pages of a website. For example, let us say that the web application (say a messaging site) immediately reflects the user input without sanitizing it. The attacker posts a link with script code. This is shown to other users of the site. If any user clicks on the malicious link, the script executes in the context of their browser. Such type of XSS is called non-persistent if the messages are not saved. If the attacker stores the malicious script permanently on the website (say in their profile or About Me webpage), it can result in persistent XSS when a victim logs in to the web site and requests the web page with the malicious script. The web site then returns the web page and the malicious script executes within the victim's browser. Out of the two types of XSS, persistent XSS is more common.

In order to test for XSS, the process may be as follows:

1. Look for input fields (like text boxes, text areas and editable drop-downs) which allow user input to be displayed or stored. For example, a Search text box on a web page whose contents the web site echoes on the Search results web page. Such input fields may or may not be vulnerable to non-persistent XSS. Another example is the input fields on a form used to create user comments. Since these comments are stored by the website permanently, such input fields may or may not be vulnerable to persistent XSS.

2. Once you have listed the suspect input fields (as explained in Step 1), the next step is to test if any of these input fields accept special characters e.g. <,>,.,' etc. which are used in script code.

3. The next step is to insert JavaScript code in each of the suspect input fields that accept the above special characters (as mentioned in Step 2). If using test automation, you should log the input field full name and path using JavaScript. If testing manually, you may want to test with a JavaScript alert statement (that shows a message pop-up box).

4. Website security bugs are filed for web pages with input fields open to XSS attacks. The developers implement counter-measures to prevent XSS attack. Common counter-measures are HTML/ URL encoding and JavaScript/ CSS escaping. You should analyze the counter-measure(s)  used (and if the counter-measure has been implemented via a web security tool or web security framework, any limitations of the used tool or framework). The final step is to re-test the previously found input fields for XSS.

As you can see, testing for XSS vulnerability in a web application may be done in a straightforward manner. You should include the test for XSS in your test suite and run it. Further, as with other things, new XSS vectors are discovered all the time. As you get some time, analyze these vectors and implement them in your test suite.