1BO4r2U

Recommendations

Info

101 102 Web Application Penetration Testing Web Application Penetration Testing BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities. • XSS-Proxy - http: /xss-proxy.sourceforge.net/ XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool. • Backframe - http: /www.gnucitizen.org/projects/backframe/ Backframe is a full-featured attack console for exploiting WEB browsers, WEB users, and WEB applications. • WebScarab WebScarab is a framework for analyzing applications that communicate using the HTTP and HTTPS protocols. • Burp - http: /portswigger.net/burp/ Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications. • XSS Assistant - http: /www.greasespot.net/ Greasemonkey script that allow users to easily test any web application for cross-site-scripting flaws. • OWASP Zed Attack Proxy (ZAP) - OWASP_Zed_Attack_Proxy_ Project ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually. References OWASP Resources • XSS Filter Evasion Cheat Sheet Books • Joel Scambray, Mike Shema, Caleb Sima - “Hacking Exposed Web Applications”, Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0 • Dafydd Stuttard, Marcus Pinto - “The Web Application’s Handbook - Discovering and Exploiting Security Flaws”, 2008, Wiley, ISBN 978-0-470-17077-9 • Jeremiah Grossman, Robert “RSnake” Hansen, Petko “pdp” D. Petkov, Anton Rager, Seth Fogie - “Cross Site Scripting Attacks: XSS Exploits and Defense”, 2007, Syngress, ISBN-10: 1-59749- 154-3 MIME%20Types.pdf Testing for HTTP Verb Tampering (OTG-INPVAL-003) Summary The HTTP specification includes request methods other than the standard GET and POST requests. A standards compliant web server may respond to these alternative methods in ways not anticipated by developers. Although the common description is ‘verb’ tampering, the HTTP 1.1 standard refers to these request types as different HTTP ‘methods.’ The full HTTP 1.1 specification [1] defines the following valid HTTP request methods, or verbs: OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT If enabled, the Web Distributed Authoring and Version (WebDAV) extensions [2] [3] permit several more HTTP methods: PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK However, most web applications only need to respond to GET and POST requests, providing user data in the URL query string or appended to the request respectively. The standard style links trigger a GET request; form data submitted via trigger POST requests. Forms defined without a method also send data via GET by default. tion within the system will need to be verified that these alternate methods do not trigger actions without proper authentication or reveal information about the contents or workings web application. If possible, limit alternate HTTP method usage to a single page that contains no user actions, such the default landing page (example: index.html). How to Test As the HTML standard does not support request methods other than GET or POST, we will need to craft custom HTTP requests to test the other methods. We highly recommend using a tool to do this, although we will demonstrate how to do manually as well. Manual HTTP verb tampering testing This example is written using the netcat package from openbsd (standard with most Linux distributions). You may also use telnet (included with Windows) in a similar fashion. 1. Crafting custom HTTP requests • Each HTTP 1.1 request follows the following basic formatting and syntax. Elements surrounded by brackets [ ] are contextual to your application. The empty newline at the end is required. [METHOD] /[index.htm] HTTP/1.1 host: [www.example.com] • In order to craft separate requests, you can manually type each request into netcat or telnet and examine the response. However, to speed up testing, you may also store each request in a separate file. This second approach is what we’ll demonstrate in these examples. Use your favorite editor to create a text file for each method. Modify for your application’s landing page and domain. 1.1 OPTIONS OPTIONS /index.html HTTP/1.1 host: www.example.com 1.2 GET 1.4 POST POST /index.html HTTP/1.1 host: www.example.com 1.5 PUT PUT /index.html HTTP/1.1 host: www.example.com 1.6 DELETE DELETE /index.html HTTP/1.1 host: www.example.com 1.7 TRACE TRACE /index.html HTTP/1.1 host: www.example.com 1.8 CONNECT CONNECT /index.html HTTP/1.1 host: www.example.com 2. Sending HTTP requests • For each method and/or method text file, send the request to nc www.example.com 80 < OPTIONS.http.txt your web server via netcat or telnet on port 80 (HTTP): 3. Parsing HTTP responses Whitepapers • RSnake: “XSS (Cross Site Scripting) Cheat Sheet” - http: /ha.ckers.org/xss.html • CERT: “CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests” - http: /www.cert.org/advisories/CA-2000-02.html • Amit Klein: “Cross-site Scripting Explained” - http: /courses. csail.mit.edu/6.857/2009/handouts/css-explained.pdf • Gunter Ollmann: “HTML Code Injection and Cross-site Scripting” - http: /www.technicalinfo.net/papers/CSS.html • CGISecurity.com: “The Cross Site Scripting FAQ” - http: /www. cgisecurity.com/xss-faq.html • Blake Frantz: “Flirting with MIME Types: A Browser’s Perspective” - http: /www.leviathansecurity.com/pdf/Flirting%20with%20 Oddly, the other valid HTTP methods are not supported by the HTML standard [4]. Any HTTP method other than GET or POST needs to be called outside the HTML document. However, JavaScript and AJAX calls may send methods other than GET and POST. As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall. If methods such as HEAD or OPTIONS are required for your application, this increases the burden of testing substantially. Each ac- GET /index.html HTTP/1.1 host: www.example.com 1.3 HEAD HEAD /index.html HTTP/1.1 host: www.example.com • Although each HTTP method can potentially return different results, there is only a single valid result for all methods other than GET and POST. The web server should either ignore the request completely or return an error. Any other response indicates a test failure as the server is responding to methods/verbs that are unnecessary. These methods should be disabled. • An example of a failed test (ie, the server supports OPTIONS despite no need for it):
103 104 Web Application Penetration Testing Web Application Penetration Testing Automated HTTP verb tampering testing If you are able to analyze your application via simple HTTP status codes (200 OK, 501 Error, etc) - then the following bash script will test all available HTTP methods. #!/bin/bash for webservmethod in GET POST PUT TRACE CONNECT OP- TIONS PROPFIND; do printf “$webservmethod “ ; printf “$webservmethod / HTTP/1.1\nHost: $1\n\n” | nc -q 1 $1 80 | grep “HTTP/1.1” done Code copied verbatim from the Penetration Testing Lab blog [5] References Whitepapers • Arshan Dabirsiaghi: “Bypassing URL Authentication and Authorization with HTTP Verb Tampering” - http: /www.aspectsecurity. com/research-presentations/bypassing-vbaac-with-http-verbtampering Testing for HTTP Parameter pollution (OTG-INPVAL-004) Summary Supplying multiple HTTP parameters with the same name may cause an application to interpret values in unanticipated ways. By exploiting these effects, an attacker may be able to bypass input validation, trigger application errors or modify internal variables values. As HTTP Parameter Pollution (in short HPP) affects a building block of all web technologies, server and client side attacks exist. Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. For instance, RFC 3986 simply defines the term Query String as a series of field-value pairs and RFC 2396 defines classes of reversed and unreserved query string characters. Without a standard in place, web application components handle this edge case in a variety of ways (see the table below for details). By itself, this is not necessarily an indication of vulnerability. However, if the developer is not aware of the problem, the presence of duplicated parameters may produce an anomalous behavior in the application that can be potentially exploited by an attacker. As often in security, unexpected behaviors are a usual source of weaknesses that could lead to HTTP Parameter Pollution attacks in this case. To better introduce this class of vulnerabilities and the outcome of HPP attacks, it is interesting to analyze some real-life examples that have been discovered in the past. Input Validation and filters bypass In 2009, immediately after the publication of the first research on HTTP Parameter Pollution, the technique received attention from the security community as a possible way to bypass web application firewalls. One of these flaws, affecting ModSecurity SQL Injection Core Rules, represents a perfect example of the impedance mismatch between applications and filters. The ModSecurity filter would correctly blacklist the following string: select 1,2,3 from table, thus blocking this example URL from being processed by the web server: /index. aspx?page=select 1,2,3 from table. However, by exploiting the concatenation of multiple HTTP parameters, an attacker could cause the application server to concatenate the string after the ModSecurity filter already accepted the input. As an example, the URL / index.aspx?page=select 1&page=2,3 from table would not trigger the ModSecurity filter, yet the application layer would concatenate the input back into the full malicious string. Another HPP vulnerability turned out to affect Apple Cups, the well-known printing system used by many UNIX systems. Exploiting HPP, an attacker could easily trigger a Cross-Site Scripting vulnerability using the following URL: http: /127.0.0.1:631/admin /?kerberos=onmouseover=alert(1)&kerberos. The application validation checkpoint could be bypassed by adding an extra kerberos argument having a valid string (e.g. empty string). As the validation checkpoint would only consider the second occurrence, the first kerberos parameter was not properly sanitized before being used to generate dynamic HTML content. Successful exploitation would result in Javascript code execution under the context of the hosting web site. Authentication bypass An even more critical HPP vulnerability was discovered in Blogger, the popular blogging platform. The bug allowed malicious users to take ownership of the victim’s blog by using the following HTTP request: POST /add-authors.do HTTP/1.1 security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=goldshlager19test%40gmail.com(attacker email)&ok=Invite The flaw resided in the authentication mechanism used by the web application, as the security check was performed on the first blogID parameter, whereas the actual operation used the second occurrence. Expected Behavior by Application Server The following table illustrates how different web technologies behave in presence of multiple occurrences of the same HTTP parameter. Given the URL and querystring: http:/example.com/?color=red&color=blue Web Application Server Backend ASP.NET / IIS ASP / IIS PHP / Apache PHP / Zeus JSP, Servlet / Apache Tomcat JSP, Servlet / Oracle Application Server 10g JSP, Servlet / Jetty IBM Lotus Domino IBM HTTP Server mod_perl, libapreq2 / Apache Perl CGI / Apache mod_wsgi (Python) / Apache Python / Zope ASP All occurrences concatenated with a comma All occurrences concatenated with a comma Last occurrence only Last occurrence only First occurrence only First occurrence only First occurrence only Last occurrence only First occurrence only First occurrence only First occurrence only First occurrence only All occurrences in List data type (source: Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf ) How to Test Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions. However, as in-depth business logic knowledge is necessary, testing HPP requires manual testing. Automatic tools can only partially assist auditors as they tend to generate too many false positives. In addition, HPP can manifest itself in client-side and server-side components. Server-side HPP To test for HPP vulnerabilities, identify any form or action that allows user-supplied input. Query string parameters in HTTP GET requests are easy to tweak in the navigation bar of the browser. If the form action submits data via POST, the tester will need to use an intercepting proxy to tamper with the POST data as it is sent to the server. Having identified a particular input parameter to test, one can edit the GET or POST data by intercepting the request, or change the query string after the response page loads. To test for HPP vulnerabilities simply append the same parameter to the GET or POST data but with a different value assigned. For example: if testing the search_string parameter in the query string, the request URL would include that parameter name and value. http:/example.com/?search_string=kittens JSP color=red,blue color=red,blue color=blue color=blue color=red color=red color=red color=blue color=red color=red color=red color=red color=[‘red’,’blue’] The particular parameter might be hidden among several other parameters, but the approach is the same; leave the other parameters in place and append the duplicate. http:/example.com/?mode=guest&search_string=kittens&num_results=100 Append the same parameter with a different value http:/example.com/?mode=guest&search_string=kittens&num_results=100&search_string=puppies and submit the new request. Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show kittens, puppies, some combination of both (kittens,puppies or kittens~puppies or [‘kittens’,’puppies’]), may give an empty result, or error page. This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generates an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities. A more in-depth analysis would require three HTTP requests for each HTTP parameter: [1] Submit an HTTP request containing the standard parameter name and value, and record the HTTP response. E.g. page?par1=val1 [2] Replace the parameter value with a tampered value, submit and record the HTTP response. E.g. page?par1=HPP_TEST1 [3] Send a new request combining step (1) and (2). Again, save the HTTP response. E.g. page?par1=val1&par1=HPP_TEST1 [4] Compare the responses obtained during all previous steps. If the response from (3) is different from (1) and the response from (3) is also different from (2), there is an impedance mismatch that may be eventually abused to trigger HPP vulnerabilities. Crafting a full exploit from a parameter pollution weakness is beyond the scope of this text. See the references for examples and details. Client-side HPP Similarly to server-side HPP, manual testing is the only reliable technique to audit web applications in order to detect parameter pollution vulnerabilities affecting client-side components. While in the server-side variant the attacker leverages a vulnerable web application to access protected data or perform actions that either not permitted or not supposed to be executed, client-side attacks aim at subverting client-side components and technologies. To test for HPP client-side vulnerabilities, identify any form or action that allows user input and shows a result of that input back to the user. A search page is ideal, but a login box might not work (as it might not show an invalid username back to the user). Similarly to server-side HPP, pollute each HTTP parameter with %26HPP_TEST and look for url-decoded occurrences of the user-sup-
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 51: 99 100 Web Application Penetration
Page 55 and 56: 107 108 Web Application Penetration
Page 103 and 104:
203 204 Web Application Penetration
Page 105 and 106:
207 208 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

Create successful ePaper yourself

Delete template?

Save as template?