Tải bản đầy đủ - 0 (trang)
11  Decoding Multiple Encodings

11  Decoding Multiple Encodings

Tải bản đầy đủ - 0trang

URL encoding (see Recipe 4.5). For example, V+P//z== might be displayed as V%2bP%2f

%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.



Solution

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.



Discussion

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):

1.

2.

3.

4.

5.

6.



xIThJBeIucYRX4fqS+wxtR8KeKk=*

TW9uIEFwciAgMiAyMjoyNzoyMSBFRFQgMjAwNwo=†

4BJB39XF‡

F8A80EE2F6484CF68B7B72795DD31575§

0723034505560231‖

713ef19e569ded13f2c7dd379657fe5fbd44527f#



* MD5 encoded with Base 64

† SHA1 encoded with Base 64

‡ Base 36

§ Hexadecimal MD5

‖ Octal

# Hexadecimal SHA1



72 | Chapter 4: Web-Oriented Data Encoding



CHAPTER 5



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

73



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

Problem

Built-in features, such as JavaScript validation or text length limits, may prevent a wellbehaved 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.



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.

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.



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













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

5.1 Intercepting and Modifying POST Requests | 75



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

11  Decoding Multiple Encodings

Tải bản đầy đủ ngay(0 tr)

×