Web Application Security Testing with Samurai

Cross-site scripting can occur when the application accepts user input and sends it back to the browser without validating it for malicious code. There are two types of XSS attacks: reflected and stored. A stored attack injects code into the page that is persistent and will be activated by the victim's browser when requesting the page. A common example of a stored cross-site scripting attack would be a script that is injected through a comment field, forum post or guestbook. If the application doesn't guard against potentially malicious input data and allows the script to be stored, the browser of the next person to load the page will execute the malicious code.

By contrast, a reflected or nonpersistent cross-site scripting attack requires the victim to click on a link from another source. Here, instead of being stored in the Web application's database, the malicious script is encoded in the URL. XSS exploits can allow attackers to deface a Web site, redirect legitimate traffic to their own site or a site of their choice, and even steal session data through cookies.

This first test utilizes a formidable tool that enjoys wide popularity among attackers—a Web browser. Although automated tools can take the pain out of iterating over a long list of tests, the simplest method to start testing your site for XSS vulnerabilities is by using a browser. You'll need to find a page on the application you'd like to test that accepts user input and then displays it—something like a guestbook, comment field or even a search dialog that displays the search string as part of the results.

The canonical check for an XSS vulnerability is considered to be the snippet of code below:

<script>alert('xss!')</script>

If the Web site isn't properly filtering input, this script will execute in the browser and then display a pop-up message with the text “xss”. There's some bad news for my little Web application here. It's so vulnerable that this simplest of strings was able to exploit it (Figure 4).

Figure 4. XSS Vulnerability Executed

Usually, at least some form of input filtering is employed, and this string won't get through intact. By examining the source of the generated page, you can try to diagnose what characters are being filtered to craft more sophisticated strings. If you inject the same string into a slightly more secure Web form, you can see by the result that the script tags are being stripped out and the single quotes are escaped:

Name: Me!
Message: alert(\'XSS!\')

You could continue encoding different parts of the string and observing the results to try to get past the filter. Or, to speed up the process, you could use an automated tool. Samurai includes the XSS Me plugin for Firefox by Security Compass. Navigate to the page you'd like to test, then select XSS Me→Open XSS Me Sidebar from the Tools menu. Select Test all forms with top attacks from the sidebar. For the curious, the strings that the XSS Me uses can be viewed in Tools→XSS Me→Options→XSS Strings, and more strings can be added.

Figure 5 shows that XSS Me has discovered that this application is vulnerable to DOM-based XSS attacks. This is a particularly insidious way of exploiting an application, as it doesn't rely on the application embedding the malicious code in the HTML output.

Figure 5. XSS Me Test Results

Another tool that can scan for XSS vulnerabilities in Samurai is, again, w3af. This powerhouse tool is capable of scanning for and exploiting almost any vulnerability you care to name. Here, let's configure it to scan the Web application for XSS vulnerabilities.

Launch the w3af GUI from the Applications→Samurai→Discovery menu. Enter the Web site URL you'd like to test in the Target: field, and then expand the options under discovery in the plugin box. Scroll down until you find the webSpider plugin and check its box to enable it. In the pane to the right, the options for the webSpider plugin will be shown. Tick onlyForward and select Save Configuration. Now, scroll back to the top of the plugins box, and expand Audit. Scroll down to xss, and check its box to enable it (Figure 6).

Figure 6. w3af Configuration

Click Start to start the audit process. Depending on the size of the Web application, this could take a few minutes as the spider plugin discovers every URL, and then the audit plugin tests all applicable forms for XSS vulnerabilities. Once complete, navigate to the Results tab, which will itemize the vulnerabilities found.