Testing for XSS Vulnerabilities - Introduction

Cross site scripting (XSS) is second most popular type of attack on web application. It allows attackers to execute scripts in victim’s browser and perform almost any action on users behalf. For example, script may hijack sessions or redirect the user to malicious sites.

This type of attack is relatively easy to perform and difficult to protect against. There are numerous different attack vectors and attacker needs only some knowledge of web technologies (JavaScript, CSS, HTML) to perform any of them. Moreover, one vulnerable place is enough to make whole application vulnerable.

This series of posts introduces XSS testing to a fictional development team working on a web project. The introduction describes both cross site scripting and fictional project requirements.

Table of Contents

Table of contents contains list of links to all finished posts.

• Introduction
• Choosing a Scanner

Cross Site Scripting

As numerous pages explain what cross site scripting is and how it can be prevented, we will not repeat what was written elsewhere. Instead, we will only list resources we found good and useful.

Reading

If you want to know what cross site scripting is, but do not want to read lengthy articles, you will like either non-technical article on TechRepublic or short technical explanation on Acunetix.

Much longer, but still easily readable article was written by Mark "Tarquin" Wilton-Jones. Alternatively, you may like technical whitepaper full of details and step by step examples.

Finally, cheat sheet with almost all attack vectors and an old cert advisory are available too.

Codelab

Google Code University created Google Gruyer codelab for those who prefer hands-on learning. Gruyer is a simple python web application full of intentional security vulnerabilities.

The documentation explains typical web application vulnerabilities along with exercises, hints and solutions. It has special chapter on cross-site scripting.

Prevention

Prevention is also covered by multiple resources. The most complete are:

• cert advice,
• first OWASP prevention cheat sheet,
• second OWASP prevention cheat sheet,
• list of characters to be sanitized against.

We found only one finished Java sanitizer - AntiSamy library. We assume that similar tools exist for any other current programming language.

Fictional Project Requirements

We have middle sized web application and limited resources. Too simple solution would not work for us and we can not afford an expensive solution.

All our requirements are described in this chapter. First section explains our possibilities and limitations. Next sections are about our expectations and project needs.

Effort and Process

Our company can not hire dedicated penetration tester for each release. We are willing to spend some time configuring and setting up the solution, but the maintenance should be as easy as possible.

Once configured, it must be easy to re-run tests. Optimally, they could be integrated with jUnit web tests or deployed as Jenkins job. The result report must be easily understandable. Basically, the price measured in developer's time must be as low as possible.

We wish to keep configuration in version control system together with application code and our test suite. Moreover, we wish to archive tests results after each release.

Crawler Limitations

Most of the application is accessible with web spider (e.g. random clicking). The rest can be reached only if certain conditions are met. For example, user can see an attachment verification form only if he created correct order, confirmed it and added an attachment to it. It is highly unlikely that random spider would perform all those steps.

It must be possible to restrict the spider so it:

• does not log out itself,
• does not cross to another application.

Whitelist is optimal. We do not want to attack another site just because someone committed wrong link by mistake.

Other Considerations

Test framework must be able to automatically pass through SSL log-in screen. Moreover, the test must be able to deal with self signed certificate we use in our test environment.

The framework should not report 'environment and infrastructure' such as web server version disclosure or self signed certificate as vulnerabilities.

Use Cases

Two different teams will use tests and each have its own different use case.

Use Case: Test Team

Our testers have no development experience besides writing automated tests. However, we would like to teach them how to use the tool. They would have a developer available any time a question or problem arise. The testers would:

• update test suite whenever application is changed,
• run test suite before each release,
• store both test configuration and test results in version control repository.

While the tests should run with minimal human interaction, they do not have to be completely automated. If all the tool requires is to press 'start' button, it is OK for us.

Use Case: Development Team

The developers would like to deploy tests on continuous integration server. If possible, they would also include them into unit tests suite. These tests will run either from IDE on developer machine or from the continuous integration server. Such setup has two consequences.

First, development set of tests must be completely automated. No human interaction is possible.

Second, as we mentioned before, tests are not supposed to report 'infrastructure' vulnerabilities such as web server version disclosure.

Final Disclaimer

We understand that all this is no replacement for dedicated experienced penetration tester, but we would like to catch at least most obvious vulnerabilities before release.

We will try to achieve as much as possible given above constrains and report on what we will find impossible.