Tải bản đầy đủ - 0 (trang)
5  Checking for Directory Traversal with cURL

5  Checking for Directory Traversal with cURL

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

Example 7-4. Testing directory traversal with cURL



# a file with known pages, one URL per line


# file descriptor 3 is our URLs


typeset -i FAILED

# for each URL in the URLFILE

while read -u 3 URL



# call curl to fetch the page. Get the headers, too. We're

# interested in the first line that gives the status

RESPONSE=$(${CURL} -D - -s "${URL}" | head -1)


set - ${RESPONSE}



# If we got something in the 200 series, it's probably a failure

if [ $result -lt 300 ]


echo "FAIL:

$result ${URL}"



# response in the 300 series is a redirect. Need to check manually

if [ $result -lt 400 ]


echo "CHECK:

$result ${URL}"



# response in the 400 series is some kind of

# denial. That's generally considered "success"

if [ $result -lt 500 ]


echo "PASS:

$result ${URL}"


# response in the 500 series means server

# failure. Anything we haven't already accounted for

# will be called a failure.

echo "FAIL:

$result ${URL}"






7.5 Checking for Directory Traversal with cURL | 133

Example 7-5. Example pages.txt





As in the section called “Solution”, the shell script takes the text file as input.


The script will base its pass/fail decision on whether or not it was denied access to the

directory, that is, an HTTP 200 response code (which normally indicates success) is

considered failure because it means we actually saw something we shouldn’t. If our

request is denied (e.g., HTTP 400-series codes), then it is considered a passing result

because we assume we were not shown the directory’s contents. Unfortunately, there

are lots of reasons why this simplistic approach might return false results.

Some applications are configured to respond with HTTP 200 on virtually every request,

regardless of whether or not it was an error. In this case, the text of the page might say

“object not found,” but the HTTP response code gives our script no clue. It will be

reported as a failure, when it should technically pass.

Likewise, some applications redirect to an error page when there is an error. An attempt

to access a protected resource might receive an HTTP 302 (or similar) response that

redirects the browser to the login page. The solution in this recipe will flag that with

“CHECK,” but it might turn out that every URL you try ends up being a “CHECK.”

The input to this script is the key to its success, but only a human can make good input.

That is, someone has to know which URLs should be retrievable and which should

not. For example, the site’s main page (http://www.example.com/) should definitely

respond with HTTP 200, but that is not an error. In many cases, the main page will

respond with HTTP 302 or 304, but that’s normal and okay as well. It is not (normally)

an instance of directory traversal. Likewise, some sites use pretty URLs like http://

www.example.com/news/, which will return HTTP 200, but again is not an error. A person

must sit down with some of the directories in the filesystem and/or use clues in the

HTML source and come up with examples like those shown in the example

pages.txt file. The directories have to be chosen so that if the server responds with an

HTTP 200, it is a failure.

Lastly, applications that respond consistently with a 200 or 302 response, regardless

of input, can still be tested this way. You have to combine the existing solution with

some of the techniques of Recipe 7.4. Remove −i from the command line so you fetch

the page (instead of the headers) to a temporary file, and then grep for the correct string.

The correct string might be Access Denied or something similar, but

make sure it corresponds to your actual application.

134 | Chapter 7: Automating Specific Tasks with cURL

This solution flags all server responses 500 and above as errors. That is

the official HTTP standard and it is pretty consistent across all web

platforms. If your web server hands out an error 500 or above, something seriously wrong has probably occurred, either in the server itself

or in your software. If you do modify this solution, we strongly recommend that you keep the check for HTTP 500 intact.

7.6 Impersonating a Specific Kind of Web Browser or Device


Some web applications react to the User-Agent string that is passed from the web

browser. The software actually selects different pages to display or different code to

execute depending on what kind of browser it thinks it is talking to. cURL allows us

to specify what our User-Agent string will be, thus allowing us to pretend to be any

browser at all. This may allow you to simulate requests from mobile phones, Flash

players, Java applets, or other non-browser software that makes HTTP requests.


# Internet Explorer on Windows Vista Ultimate

curl -o MSIE.html -A 'Mozilla/4.0 (compatible; MSIE 7.0;

Windows NT 6.0; SLCC1; .NET CLR 2.0.50727;

Media Center PC 5.0; .NET CLR 3.0.04506)' http://www.example.com/

# Firefox on MacOS X

curl -o FFMac.html -A 'Mozilla/5.0 (Macintosh; U;

Intel Mac OS X; en-US; rv:

Gecko/20070309 Firefox/' http://www.example.com/

# "Blazer" web browser on PalmOS devices

curl -o Palm.html -A 'Mozilla/4.0 (compatible; MSIE 6.0; Windows 98;

PalmSource/hspr-H102; Blazer/4.0) 16;320x320'



There is no rhyme or reason to User-Agent strings, except the vestigial “Mozilla” at the

beginning of the string—a reminder of the browser wars. There are many databases

and websites that collect these strings, but as a tester, you want to gather them differently. You want to find out from the developers or from the source code itself which

user agents the code responds to (if any). That way you can determine how many

different kinds of tests you need to do. You may want to talk to operations staff to get

some of your web server logs and look at what User-Agents you’re seeing in the wild.

If you want to browse around interactively, impersonating another device, take a look

at Recipe 7.7. By poking around interactively, you may discover that your application

7.6 Impersonating a Specific Kind of Web Browser or Device | 135

does react to the User-Agent, and, therefore, you need to make some test cases based

on this recipe.

Providing customized content

Yahoo! is a major website that reacts to the User-Agent string. If you choose something

it doesn’t recognize, it will send a very small web page (and one that has very little

JavaScript and fewer advertisements). If your User-Agent is recognizable as Internet

Explorer, Firefox, or another well-known browser, Yahoo! will deliver customized

content—including JavaScript that is carefully tuned to execute correctly in your web

browser. One of the reasons Yahoo! does this is to provide a good-looking interface to

new devices that they have never heard of before. The first person to visit http://www

.yahoo.com/ with a Nintendo Wii or an Apple iPhone got a generic page that probably

rendered pretty well, but did not have all the features of Yahoo! when viewed in a

browser. Eventually, as Yahoo! becomes aware of the capabilities of the Wii or the

iPhone, they will change their site to react differently, based on the User-Agent.

Reacting to User-Agent is rare

Most web applications don’t react to browsers at all. You only need to consider this

testing technique if you know for a fact that your application behaves this way. Note

that many sites and applications that use complex cascading style sheets (CSS) or asynchronous JavaScript and XML (AJAX) will have a lot of complex JavaScript code that

loads differently in the browser depending on which browser it is. This is not the same

as the User-Agent string and having the server perform different operations based on

what browser requests the page. Many sites send JavaScript that will be executed differently depending on the browser. Few look at the User-Agent string at run time.

Realize that, if you’re one of the lucky few who has software that responds differently

to different User-Agents, this will increase your test matrix significantly. Tests for vulnerabilities like cross-site scripting (XSS), SQL injection, or session fixation will have

to be done with representatives of various different kinds of browsers to be sure that

all the code is tested.

7.7 Interactively Impersonating Another Device


If testing with cURL shows that your site responds to the User-Agent string (see Recipe 7.6), you might want to just probe around interactively and see what your website

looks like when a search engine (like Google, Yahoo!, or MSN) sees it.

136 | Chapter 7: Automating Specific Tasks with cURL

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

5  Checking for Directory Traversal with cURL

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