%2f%3d%3d. You’ll need to be aware of this so that when you’ve completed one round
of successful decoding, you treat the result as potentially more encoded data.
Sometimes a single parameter is actually a specially structured payload that carries
many parameters. For example, if we see AUTH=dGVzdHVzZXI6dGVzdHB3MTIz, then we
might be tempted to consider AUTH to be one parameter. When we realize that the value
decodes to testuser:testpw123, then we realize that it is actually a composite parameter
containing a user ID and a password, with a colon as a delimiter. Thus, our tests will
have to manipulate the two pieces of this composite differently. The rules and processing in the web application are almost certainly different for user IDs and passwords.
We don’t usually include quizzes as a follow-up to a recipe, but in this case it might be
worthwhile. Recognizing data encodings is a pretty important skill, and an exercise
here may help reinforce what we’ve just explained. Remember that some of them may
be encoded more than once. See if you can determine the kind of data for each of the
following (answers in the footnotes):
* MD5 encoded with Base 64
† SHA1 encoded with Base 64
‡ Base 36
§ Hexadecimal MD5
# Hexadecimal SHA1
72 | Chapter 4: Web-Oriented Data Encoding
Tampering with Input
Beware of the man who won’t be bothered with details.
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
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
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.
5.1 Intercepting and Modifying POST Requests
situation, we’ll show you how to send modified requests from outside the browser.
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.
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.
74 | Chapter 5: Tampering with Input
Figure 5-1. Modifying an intercepted request
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.
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
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