Tải bản đầy đủ - 0 (trang)
8  Uploading Files with Malicious Names

8  Uploading Files with Malicious Names

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

Figure 5-8. The status bar shows the full image location



First, create a test image file on your local computer. Make several copies of it with

various invalid or suspect characters in the name, such as single quotes, equals signs,

or parentheses. For example, in the Windows NTFS filesystem,

'onerror='alert('XSS')' a='.jpg is a valid filename. Microsoft Paint should suffice to

create this image, or you can copy and rename an existing image. Unix and Linux

filesystems may allow further special characters, such as pipe (|) and slashes.

Upload this file via your application’s form and complete whatever steps are necessary

to find where the file is displayed or downloaded. In the page where the file is displayed,

or the link to download it is listed, find the filename in the source code.

For an application where the file is downloaded, you will likely find a link to the file’s

location on the server. When the file is an image and is directly displayed in an application, you should find an image tag referring to the file. Ensure that the link or image

location does not simply echo back the exact same filename. Ideally, the URL will

contain an ID number rather than the actual filename. Alternatively, the special characters in the filename may be escaped via slashes or an encoding. Simply echoing back

the exact same filename may leave your application open to attack.

For example, the web-based mail application displayed in Figure 5-8 escapes filenames

via backslashes.



Discussion

There are a few key circumstances where a file upload may reveal a vulnerability. These

include operating system code injection, cross-site scripting, SQL injection, or abuse

of file processing. Code injection at the server level is not a typical application-level

security concern. Yet because files provide such a straightforward path to the server, it

is worth mentioning here.



Code injection

Often, the server operating system can be identified via the response headers, as discussed in Recipe 3.6. On some Unix or Linux filesystems in particular, filenames may

5.8 Uploading Files with Malicious Names | 89



include special characters such as slashes, pipes, and quotes. A few unusual and potential dangerous filenames are shown in Example 5-5, using Mac OS X and the associated HFS filesystem. If the headers reveal the application framework or language

instead, you may try special characters for that language. When uploading a filename

including these special characters, if the application doesn’t automatically escape or

replace the special characters, your application may be at risk. Experiment with the

special characters—if you can get your application to crash or display incorrect behavior, it’s likely that further manipulation could fully exploit your server or

application.

Example 5-5. A few filenames including special characters

-rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--



1

1

1

1

1

1

1



user

user

user

user

user

user

user



group

group

group

group

group

group

group



10

31

43

29

28

15

72



Jul

Jul

Jul

Jul

Jul

Jul

Jul



18

18

20

15

15

18

20



21:43

21:42

10:38

13:56

13:56

23:01

10:40



';alert("XSS");x='

|ls

|ls%20-al

" || cat /etc/passwd; "

' having 1=1

" -
test




A trivial example for a Unix- or Linux-based server is the filename |ls -al. If uploaded

without escaping or renaming, a server script attempting to open the file might instead

return the contents of the directory (similar to the dir command in DOS). There are

far worse attacks, including some that delete or create files in the filesystem.

For those testing from an operating system that does not allow special characters in

filenames (such as Windows), remember that it’s possible to change the name of a file

as you are uploading it, even if you cannot save the file on disk with special characters.

See Recipe 5.1 for more details on using TamperData to change data sent to the server.

Cross-site-scripting. Even if code injection isn’t possible, if filenames are not escaped

properly, cross-site scripting is still a potential issue. Any filename needs to escape or

encode HTML special characters before being saved to disk. Preferably, the entire filename should be replaced by a unique identifier.

If a raw, unchanged filename is sent to the browser, the following HTML output can

turn from
ror='alert( 'XSS')' a='.jpg' />. This is a prime example of very simple JavaScript

injection, a major method of carrying out cross-site scripting attacks.

SQL injection. While code injection attacks the server or language running the application

and cross-site scripting targets the browser, SQL injection focuses on maliciously accessing the database. If the uploaded file is stored in a database, rather than as a file on

the server, SQL injection is the area you should test, rather than code injection.

The most common special character required for SQL injection is the single quote. Try

adding a single quote to a filename and see what happens as the file is saved to the

database. If your application returns an error, chances are it is vulnerable to SQL

injection.

90 | Chapter 5: Tampering with Input



The act of uploading and then processing files paves the way for other

security concerns beyond the name of the file. Any files uploaded in this

way are application input and should be tested as thoroughly as HTTP

driven input. Each file format will need to be tested according to the

expectations of that format, but we can present a brief summary of file

content related risks.Take care storing these files on your computer. You

could cause odd behavior with your antivirus software, freeze your

computer, or violate corporate policy. Be careful!



5.9 Uploading Large Files

Problem

If your web application allows users to upload files, there is one basic test that you must

apply—attempt to upload a large file beyond the limits of what your application usually

anticipates.



Solution

What constitutes “large” depends on your application, but the general rule of thumb

is: upload a file 100 times larger than normal usage. If your application is built to

accommodate files up to 5 megabytes, try one with 500 megabytes.

If you’re having trouble creating a file that large, modify the program in Example 5-2

to make a file much larger than a megabyte and use it. If you need binary data, you can

change rand(95) to be rand(255) and remove the line below that adds 32 to the result.

Once you have your sample largefile.txt, upload it to your application where the

application allows.



Discussion

This test is nothing more than an extreme example of boundary-value testing. A lack

of validation on file upload size may be caught by normal testing. An application that

doesn’t limit file upload size, on the other hand, will usually freeze completely—

requiring a restart of the web server. Typically there will be no error message or stack

trace when the server memory fills up—the system just gets progressively slower until

it no longer responds. This is an indirect denial of service, as the attack may be repeated

as soon as the server is back online.

You’re going to want to execute this test on a fast connection, preferably as close to the

actual server as possible. If you can run the web server on your desktop and upload a

file from your desktop, all the better. The point of this test is to ensure your server and

application properly reject large files—not to take a nap as you test your bandwidth.



5.9 Uploading Large Files | 91



5.10 Uploading Malicious XML Entity Files

Problem

XML is the de facto standard for web services and web-compatible data storage. The

parts of an application that process XML are important areas to test. While normal

testing should involve uploading and processing valid and malformed XML documents,

there are security precautions one should take with XML as well. This test attacks the

XML processing modules used to extract data for use in your application.



Solution

This specific attack is called the “billion laughs” attack because it creates a recursive

XML definition that generates one billion “Ha!” strings in memory (if your XML parser

is vulnerable). Identify a form or HTTP request within your application that accepts

an XML file upload. Attacking AJAX applications with the billion laughs is discussed

in Chapter 10.

You will need to create a file on your local computer containing the malicious XML.

Insert or upload XML into your application like what is shown in Example 5-6.

Example 5-6. Billion laughs XML data












...





]>

&ha30;



For the sake of brevity, we removed a few lines from this XML document. The entire

document can also be generated programmatically via the program shown in Example 5-7.

Example 5-7. Generating the billion laughs attack

#!/usr/bin/perl

# number of entities is 2^30 if $entities == 30

$entities = 30;

$i = 1;

open OUT, ">BillionLaughs.txt" or die "cannot open BillionLaughs.txt";

print OUT "\n";

print OUT "


92 | Chapter 5: Tampering with Input



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

8  Uploading Files with Malicious Names

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

×