4.0
1NSchAb
1NSchAb
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
188<br />
Web Application Penetration Testing<br />
• Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)<br />
Tools<br />
• Metasploit’s payload generation functionality<br />
• Intercepting proxy<br />
References<br />
• OWASP - Unrestricted File Upload - https://www.owasp.org<br />
index.php/Unrestricted_File_Upload<br />
• Why File Upload Forms are a Major Security Threat - http:/<br />
www.acunetix.com/websitesecurity/upload-forms-threat/<br />
• File upload security best practices: Block a malicious file upload<br />
http://www.computerweekly.com/answer/File-uploadsecurity-best-practices-Block-a-malicious-file-upload<br />
• Overview of Malicious File Upload Attacks<br />
http:/securitymecca.com/article/overview-of-malicious-fileupload-attacks/<br />
• Stop people uploading malicious PHP files via forms<br />
http://stackoverflow.com/questions/602539/stop-peopleuploading-malicious-php-files-via-forms<br />
• How to Tell if a File is Malicious<br />
http://www.techsupportalert.com/content/how-tell-if-filemalicious.htm<br />
• CWE-434: Unrestricted Upload of File with Dangerous Type<br />
http://cwe.mitre.org/data/definitions/434.html<br />
• Implementing Secure File Upload<br />
http://infosecauditor.wordpress.com/tag/malicious-fileupload/<br />
• Watchful File Upload<br />
http://palizine.plynt.com/issues/2011Apr/file-upload/<br />
• Matasploit Generating Payloads<br />
http://www.offensive-security.com/metasploit-unleashed/<br />
Generating_Payloads<br />
• Project Shellcode – Shellcode Tutorial 9: Generating<br />
Shellcode Using Metasploit http://www.projectshellcode.<br />
com/?q=node/29<br />
• Anti-Malware Test file - http://www.eicar.org/86-0-Intended<br />
use.html<br />
Remediation<br />
While safeguards such as black or white listing of file extensions,<br />
using “Content-Type” from the header, or using a file type recognizer<br />
may not always be protections against this type of vulnerability.<br />
Every application that accepts files from users must have<br />
a mechanism to verify that the uploaded file does not contain<br />
malicious code. Uploaded files should never be stored where the<br />
users or attackers can directly access them.<br />
Client-Side Testing<br />
Client-Side testing is concerned with the execution of code on<br />
the client, typically natively within a web browser or browser<br />
plugin. The execution of code on the client-side is distinct from<br />
executing on the server and returning the subsequent content.<br />
Testing for DOM-based Cross site scripting<br />
(OTG-CLIENT-001)<br />
Summary<br />
DOM-based Cross-Site Scripting is the de-facto name for XSS<br />
bugs which are the result of active browser-side content on a<br />
page, typically JavaScript, obtaining user input and then doing<br />
something unsafe with it which leads to execution of injected<br />
code. This document only discusses JavaScript bugs which lead<br />
to XSS.<br />
The DOM, or Document Object Model, is the structural format<br />
used to represent documents in a browser. The DOM enables<br />
dynamic scripts such as JavaScript to reference components of<br />
the document such as a form field or a session cookie. The DOM<br />
is also used by the browser for security - for example to limit<br />
scripts on different domains from obtaining session cookies for<br />
other domains. A DOM-based XSS vulnerability may occur when<br />
active content, such as a JavaScript function, is modified by a<br />
specially crafted request such that a DOM element that can be<br />
controlled by an attacker.<br />
There have been very few papers published on this topic and, as<br />
such, very little standardization of its meaning and formalized<br />
testing exists.<br />
How to Test<br />
Not all XSS bugs require the attacker to control the content returned<br />
from the server, but can instead abuse poor JavaScript<br />
coding practices to achieve the same results. The consequences<br />
are the same as a typical XSS flaw, only the means of delivery is<br />
different.<br />
In comparison to other cross site scripting vulnerabilities (reflected<br />
and stored XSS), where an unsanitized parameter is<br />
passed by the server, returned to the user and executed in the<br />
context of the user’s browser, a DOM-based XSS vulnerability<br />
controls the flow of the code by using elements of the Document<br />
Object Model (DOM) along with code crafted by the attacker to<br />
change the flow.<br />
Due to their nature, DOM-based XSS vulnerabilities can be executed<br />
in many instances without the server being able to determine<br />
what is actually being executed. This may make many of<br />
the general XSS filtering and detection techniques impotent to<br />
such attacks.<br />
The first hypothetical example uses the following client side<br />
code:<br />
An attacker may append #alert(‘xss’) to the affected<br />
page URL which would, when executed, display the alert<br />
box. In this instance, the appended code would not be sent to<br />
the server as everything after the # character is not treated as<br />
part of the query by the browser but as a fragment. In this example,<br />
the code is immediately executed and an alert of “xss” is<br />
displayed by the page. Unlike the more common types of cross