Tampering with Input

Beware of the man who won't be bothered with details.

—William Feather

At the most basic level, a test case is just a series of inputs and expected outputs. Security testing requires tweaking input in ways normally prohibited by well-behaved, normal web browsers. This chapter lays the foundation for security tests. Together with the ability to observe output (discussed in Chapter 3), these make up the fundamentals for designing security test cases for any web application.

Security vulnerabilities can be exploited from any type of input. We intend to take you beyond functional testing, and help you tamper with forms, files, GET, POST, AJAX, cookies, headers, and more.

This chapter suggests many ways of tampering with input and may even include common attack patterns, but does not go into detail on the most famous of web security flaws such as XSS, CSRF, and SQL Injection. These will be covered in Chapter 12.

Depending on the environment you are given, you might be executing your tests against development servers, staging (i.e., pre-production ), or separate QA/testing servers. We would discourage testing against production web

applications, unless you really have no alternative. Depending on which environment you're using, you have a few pitfalls to be aware of and avoid.

If you test against development, be aware that your test environment probably does not map well to your production environment. Web servers, application servers, and the application itself may be configured differently than in production. Tests that fail on development servers should be tested more carefully in a more production-like environment.

Some of the tests we show in this chapter can lead to denial-of-service conditions. If you're testing in a pre-production environment, be sure that crashing that system is acceptable.

If you test a pre-production or QA environment, does it really have the same properties as production? Many significant websites use load balancers, application firewalls, and other devices that are too expensive to buy in quantity. Thus, the production application is protected by mechanisms that the QA or staging version is not. Consider this carefully when analyzing your findings. You need to make accurate statements about risk (remember that we are providing evidence, as we discussed in Chapter 1). It is important that you are able to accurately describe not only the application's failure but also the possibility of that failure occurring in production.

Lastly, it has been said that "with great power comes great responsibility." Take care with the examples in this and the subsequent chapters. Most of our recipes are harmless. Some create minor inconveniences if your application is vulnerable. We try to demonstrate the vulnerability convincingly without actually inflicting harm. Because we're often using real hacker techniques, however, many of the recipes are just a step or two away from being highly destructive.

It isn't cool to destroy, even if you have permission to "hack" on your own systems. It isn't cool if you discover that command injection is possible and make your web server (that isn't backed up because it's a QA system) delete all the test data for everybody's tests. Use these recipes as much as you can, but use them wisely.

Recipe 5.1. Intercepting and Modifying POST Requests 5.1.1. Problem

Built-in features, such as JavaScript validation or text length limits, may prevent a well-behaved web browser from sending certain kinds of malicious input. Attackers, however, have many ways to bypass these client-side limitations.

In order to test for this situation, we'll show you how to send modified requests from outside the browser.

5.1.2. Solution

Launch WebScarab and configure Firefox to use it as a proxy (as described in Chapter 3). Log into your application and navigate to the functionality you'd like to test. When you are ready to submit a request—but before you do—open WebScarab.

Within WebScarab, via the Intercept tab, click the "Intercept Requests" checkbox. From this point on, WebScarab will prompt you for every new page or AJAX request. It will ask you if you'd like to edit the request prior to sending it to the server. Notice that your page will not load until you confirm or deny the request.

From the "Edit Request" window, you may insert, modify, or delete request headers as you like. Double-click any request header to modify it—you can even modify the header names on the left. In Figure 5-1, you can see modification to the SSN variable.

Figure 5-1. Modifying an intercepted request

Additionally, you may edit the raw request in plaintext form via the ^Raw tab. This makes it easy to copy and paste the entire request, so that you may repeat the exact same test later. Saving the request by pasting it into a test case allows you to save data for regression testing.

When you have finished, you can disable the interception of requests by deselecting the checkbox in any of the "Edit Request" windows. If there are a number of waiting requests, the "Cancel ALL Intercepts" button may come in handy.

5.1.3. Discussion

As a web proxy (for more on web proxies, see Chapter 3), WebScarab intercepts and modifies data after it leaves your browser but before it reaches the server. By modifying the data en route, it circumvents any restrictions or

modifications specified by the page.

Note that browsing with "Intercept Requests" enabled will initiate an "Edit Request" window for every new page. Don't forget to uncheck "Intercept Requests"! It can be quite annoying to have to click through several Edit Requests if you forget to turn it off when you're done.

Notice that the SSN variable in Figure 5-1 transmitted five digits. This is despite the fact that the source HTML, as shown in Example 5-1, limits the ^SSN field to four characters, as shown in Figure 5-2 and this example.

Example 5-1. HTML that creates the form shown in Figure 5-2

<TD ALIGN="Left" VALIGN="middle" BGCOLOR="#CCCCCC" NOWRAP>

<FONT FACE="Helvetica" SIZE="3" Color="BLACK">

<INPUT TYPE="PASSWORD" NAME="SSN" MAXLENGTH="4">

</FONT>

</TD>

Figure 5-2. Logging into a bank—last four SSN digits only

Sending five digits in a field expecting four is just one example of the kind of modification WebScarab makes possible.

Once you have established your ability to provide unusual data, it's worthwhile to ensure that your application handles these exceptions gracefully. This technique is instrumental when testing for common security problems, discussed in Chapter 9.

WebScarab allows you to modify any request header, even the URL to which the request is sent. This makes it easy to modify both GET and POST information simultaneously, an ability that other tools, such as TamperData, lack.