1BO4r2U

Recommendations

Info

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.
187 188 Web Application Penetration Testing Web Application Penetration Testing Automated testing has only very limited success at identifying and validating DOM-based XSS as it usually identifies XSS by sending a specific payload and attempts to observe it in the server response. This may work fine for the simple example provided below, where the message parameter is reflected back to the user: var pos=document.URL.indexOf(“message=”)+5; document.write(document.URL.substring(pos,document.URL. length)); but may not be detected in the following contrived case: var navAgt = navigator.userAgent; if (navAgt.indexOf(“MSIE”)!=-1) { document.write(“You are using IE as a browser and visiting site: “ + document.location.href + “.”); } else { document.write(“You are using an unknown browser.”); } that is executed by the application inside the victim’s browser. This vulnerability can have many consequences, like disclosure of a user’s session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims or the application behavior. How to Test Such vulnerability occurs when the application lacks of a proper user supplied input and output validation. JavaScript is used to dynamically populate web pages, this injection occur during this content processing phase and consequently affect the victim. When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers. For reference see the DOM XSS Wiki. The following script does not perform any validation of the variable rr that contains the user supplied input via the query string and additionally does not apply any form of encoding: var rr = location.search.substring(1); if(rr) window.location=decodeURIComponent(rr); This implies that an attacker could inject JavaScript code simply by submitting the following query string: www.victim. com/?javascript:alert(1) References OWASP Resources • DOM based XSS Prevention Cheat Sheet • DOMXSS.com - http://www.domxss.com Whitepapers • Browser location/document URI/URL Sources - https://code. google.com/p/domxsswiki/wiki/LocationSources • i.e., what is returned when the user asks the browser for things like document.URL, document.baseURI, location, location.href, etc. Testing for HTML Injection (OTG-CLIENT-003) Summary HTML injection is a type of injection issue that occurs when a user is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. This vulnerability can have many consequences, like disclosure of a user’s session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims. How to Test This vulnerability occurs when the user input is not correctly sanitized and the output is not encoded. An injection allows the attacker to send a malicious HTML page to a victim. The targeted browser will not be able to distinguish (trust) the legit from the malicious parts and consequently will parse and execute all as legit in the victim context. var userposition=location.href.indexOf(“user=”); var user=location.href.substring(userposition+5); document.write(“Hello, “ + user +””); In both examples, an input like the following: http:/vulnerable.site/page.html?user= will add to the page the image tag that will execute an arbitrary JavaScript code inserted by the malicious user in the HTML context. Black Box testing Black box testing for HTML Injection 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 HTML Injection vulnerabilities: For example, looking at the following URL: http:/www.domxss.com/domxss/01_Basics/06_jquery_old_html.html For this reason, automated testing will not detect areas that may be susceptible to DOM-based XSS unless the testing tool can perform addition analysis of the client side code. Manual testing should therefore be undertaken and can be done by examining areas in the code where parameters are referred to that may be useful to an attacker. Examples of such areas include places where code is dynamically written to the page and elsewhere where the DOM is modified or even where scripts are directly executed. Further examples are described in the excellent DOM XSS article by Amit Klein, referenced at the end of this section. References OWASP Resources • DOM based XSS Prevention Cheat Sheet Whitepapers • Document Object Model (DOM) - http://en.wikipedia.org/wiki/ Document_Object_Model • DOM Based Cross Site Scripting or XSS of the Third Kind - Amit Klein http://www.webappsec.org/projects/articles/071105.shtml • Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources • i.e., what is returned when the user asks the browser for things like document.URL, document.baseURI, location, location.href, etc. Testing for JavaScript Execution (OTG-CLIENT-002) Summary A JavaScript Injection vulnerability is a subtype of Cross Site Scripting (XSS) that involves the ability to inject arbitrary JavaScript code Black Box testing Black box testing for JavaScript Execution 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 JavaScript Execution vulnerabilities: For example, looking at the following URL: http://www.domxss. com/domxss/01_Basics/04_eval.html function loadObj(){ var cc=eval(‘(‘+aMess+’)’); document.getElementById(‘mess’).textContent=cc.message; } if(window.location.hash.indexOf(‘message’)==-1) var aMess=”({\”message\”:\”Hello User!\”})”; else var aMess=location.hash.substr(window.location.hash.index- Of(‘message=’)+8); The page contains the following scripts: The above code contains a source ‘location.hash’ that is controlled by the attacker that can inject directly in the ‘message’ value a JavaScript Code to take the control of the user browser. There is a wide range of methods and attributes that could be used to render HTML content. If these methods are provided with an untrusted input, then there is an high risk of XSS, specifically an HTML injection one. Malicious HTML code could be injected for example via innerHTML, that is used to render user inserted HTML code. If strings are not correctly sanitized the problem could lead to XSS based HTML injection. Another method could be document.write() When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers. For reference see the DOM XSS Wiki. The innerHTML property sets or returns the inner HTML of an element. An improper usage of this property, that means lack of sanitization from untrusted input and missing output encoding, could allow an attacker to inject malicious HTML code. Example of Vulnerable Code: The following example shows a snippet of vulnerable code that allows an unvalidated input to be used to create dynamic html in the page context: var userposition=location.href.indexOf(“user=”); var user=location.href.substring(userposition+5); document.getElementById(“Welcome”).innerHTML=” Hello, “+user; In the same way, the following example shows a vulnerable code using the document.write() function: The HTML code will contains the following script: function setMessage(){ var t=location.hash.slice(1); $(“div[id=”+t+”]”).text(“The DOM is now loaded and can be manipulated.”); } $(document).ready(setMessage ); $(window).bind(“hashchange”,setMessage) Show HereShowing Message1 Show HereShowing Message2 Show HereShowing Message3 It is possible to inject HTML code. References OWASP Resources • DOM based XSS Prevention Cheat Sheet • DOMXSS.com - http://www.domxss.com
Page 1 and 2:
1 2 THE ICONS BELOW REPRESENT WHAT
Page 3 and 4:
3 4 Testing Guide Frontispiece Test
Page 5 and 6:
7 8 Testing Guide Introduction Test
Page 7 and 8:
11 12 Testing Guide Introduction Te
Page 9 and 10:
15 16 Testing Guide Introduction Te
Page 11 and 12:
19 20 Testing Guide Introduction of
Page 13 and 14:
23 24 Web Application Penetration T
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44: 83 84 Web Application Penetration T
Page 51 and 52: 99 100 Web Application Penetration
Page 93: 183 184 Web Application Penetration
Page 107 and 108: 211 212 Reporting Appendix Test ID
Page 109 and 110: 215 216 Appendix Appendix Testing -
Page 111: 219 220 LDAP Injection For details
show all

1BO4r2U

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?