1BO4r2U

185 186
Web Application Penetration Testing
Web Application Penetration Testing
Example
Suppose a picture sharing application allows users to upload their .gif
or .jpg graphic files to the web site. What if an attacker is able to upload
a PHP shell, or exe file, or virus? The attacker may then upload
the file that may be saved on the system and the virus may spread itself
or through remote processes exes or shell code can be executed.
How to Test
Generic Testing Method
• Review the project documentation and use exploratory testing
looking at the application/system to identify what constitutes and
“malicious” file in your environment.
• Develop or acquire a known “malicious” file.
• Try to upload the malicious file to the application/system and verify
that it is correctly rejected.
• If multiple files can be uploaded at once, there must be tests in
place to verify that each file is properly evaluated.
Specific Testing Method 1
• Using the Metasploit payload generation functionality generates a
shellcode as a Windows executable using the Metasploit “msfpayload”
command.
• Submit the executable via the application’s upload functionality
and see if it is accepted or properly rejected.
Specific Testing Method 2
• Develop or create a file that should fail the application malware
detection process. There are many available on the Internet such as
ducklin.htm or ducklin-html.htm.
• Submit the executable via the application’s upload functionality
and see if it is accepted or properly rejected.
Specific Testing Method 3
• Set up the intercepting proxy to capture the “valid” request for an
accepted file.
• Send an “invalid” request through with a valid/acceptable file extension
and see if the request is accepted or properly rejected.
Related Test Cases
• Test File Extensions Handling for Sensitive Information (OTG-CON-
FIG-003)
• Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)
Tools
• Metasploit’s payload generation functionality
• Intercepting proxy
References
• OWASP - Unrestricted File Upload - https://www.owasp.org/index.php/Unrestricted_File_Upload
• Why File Upload Forms are a Major Security Threat - http://
www.acunetix.com/websitesecurity/upload-forms-threat/
• File upload security best practices: Block a malicious file upload
- http://www.computerweekly.com/answer/File-upload-security-best-practices-Block-a-malicious-file-upload
• Overview of Malicious File Upload Attacks - http://securitymecca.com/article/overview-of-malicious-file-upload-attacks/
• Stop people uploading malicious PHP files via forms - http://
stackoverflow.com/questions/602539/stop-people-uploadingmalicious-php-files-via-forms
• How to Tell if a File is Malicious - http://www.techsupportalert.
com/content/how-tell-if-file-malicious.htm
• CWE-434: Unrestricted Upload of File with Dangerous Type -
http://cwe.mitre.org/data/definitions/434.html
• Implementing Secure File Upload - http://infosecauditor.wordpress.com/tag/malicious-file-upload/
• Watchful File Upload - http://palizine.plynt.com/issues/2011Apr/file-upload/
• Matasploit Generating Payloads - http://www.offensive-security.com/metasploit-unleashed/Generating_Payloads
• Project Shellcode – Shellcode Tutorial 9: Generating Shellcode
Using Metasploit http://www.projectshellcode.com/?q=node/29
• Anti-Malware Test file - http://www.eicar.org/86-0-Intendeduse.html
Remediation
While safeguards such as black or white listing of file extensions,
using “Content-Type” from the header, or using a file type recognizer
may not always be protections against this type of vulnerability.
Every application that accepts files from users must have a
mechanism to verify that the uploaded file does not contain malicious
code. Uploaded files should never be stored where the users
or attackers can directly access them.
Client-Side Testing
Client-Side testing is concerned with the execution of code on the
client, typically natively within a web browser or browser plugin.
The execution of code on the client-side is distinct from executing
on the server and returning the subsequent content.
Testing for DOM-based Cross site scripting
(OTG-CLIENT-001)
Summary
DOM-based Cross-Site Scripting is the de-facto name for XSS
bugs which are the result of active browser-side content on a
page, typically JavaScript, obtaining user input and then doing
something unsafe with it which leads to execution of injected
code. This document only discusses JavaScript bugs which lead
to XSS.
The DOM, or Document Object Model, is the structural format
used to represent documents in a browser. The DOM enables dynamic
scripts such as JavaScript to reference components of the
document such as a form field or a session cookie. The DOM is also
used by the browser for security - for example to limit scripts on
different domains from obtaining session cookies for other domains.
A DOM-based XSS vulnerability may occur when active
content, such as a JavaScript function, is modified by a specially
crafted request such that a DOM element that can be controlled
by an attacker.
There have been very few papers published on this topic and, as
such, very little standardization of its meaning and formalized
testing exists.
How to Test
Not all XSS bugs require the attacker to control the content returned
from the server, but can instead abuse poor JavaScript
coding practices to achieve the same results. The consequences
are the same as a typical XSS flaw, only the means of delivery is
different.
In comparison to other cross site scripting vulnerabilities (reflected
and stored XSS), where an unsanitized parameter is passed
by the server, returned to the user and executed in the context of
the user’s browser, a DOM-based XSS vulnerability controls the
flow of the code by using elements of the Document Object Model
(DOM) along with code crafted by the attacker to change the flow.
Due to their nature, DOM-based XSS vulnerabilities can be executed
in many instances without the server being able to determine
what is actually being executed. This may make many of the
general XSS filtering and detection techniques impotent to such
attacks.
document.write(“Site is at: “ + document.location.href + “.”);
The first hypothetical example uses the following client side code:
An attacker may append #alert(‘xss’) to the affected
page URL which would, when executed, display the alert
box. In this instance, the appended code would not be sent to the
server as everything after the # character is not treated as part
of the query by the browser but as a fragment. In this example,
the code is immediately executed and an alert of “xss” is displayed
by the page. Unlike the more common types of cross site scripting
(Stored and Reflected) in which the code is sent to the server
and then back to the browser, this is executed directly in the user’s
browser without server contact.
The consequences of DOM-based XSS flaws are as wide ranging
as those seen in more well known forms of XSS, including cookie
retrieval, further malicious script injection, etc. and should therefore
be treated with the same severity.
Black Box testing
Blackbox testing for DOM-Based XSS is not usually performed
since access to the source code is always available as it needs to
be sent to the client to be executed.
Gray Box testing
Testing for DOM-Based XSS vulnerabilities:
JavaScript applications differ significantly from other types of
applications because they are often dynamically generated by
the server, and to understand what code is being executed, the
website being tested needs to be crawled to determine all the
instances of JavaScript being executed and where user input
is accepted. Many websites rely on large libraries of functions,
which often stretch into the hundreds of thousands of lines of
code and have not been developed in-house. In these cases,
top-down testing often becomes the only really viable option,
since many bottom level functions are never used, and analyzing
them to determine which are sinks will use up more time than is
often available. The same can also be said for top-down testing
if the inputs or lack thereof is not identified to begin with.
User input comes in two main forms:
• Input written to the page by the server in a way that does not
allow direct XSS
• Input obtained from client-side JavaScript objects
Here are two examples of how the server may insert data into
JavaScript:
var data = “”;
var result = someFunction(“”);
And here are two examples of input from client-side JavaScript
objects:
var data = window.location;
var result = someFunction(window.referer);
While there is little difference to the JavaScript code in how they
are retrieved, it is important to note that when input is received
via the server, the server can apply any permutations to the data
that it desires, whereas the permutations performed by JavaScript
objects are fairly well understood and documented, and
so if someFunction in the above example were a sink, then the
exploitability of the former would depend on the filtering done
by the server, whereas the latter would depend on the encoding
done by the browser on the window.referer object.
Stefano Di Paulo has written an excellent article on what browsers
return when asked for the various elements of a URL using
the document. and location. attributes.
Additionally, JavaScript is often executed outside of
blocks, as evidenced by the many vectors which have led to XSS
filter bypasses in the past, and so, when crawling the application,
it is important to note the use of scripts in places such as
event handlers and CSS blocks with expression attributes.
Also, note that any off-site CSS or script objects will need to be
assessed to determine what code is being executed.