1BO4r2U

Recommendations

Info

133 134 Web Application Penetration Testing Web Application Penetration Testing userName = ]]> this will become: ]]> which is not a valid XML fragment. Another test is related to CDATA tag. Suppose that the XML document is processed to generate an HTML page. In this case, the CDATA section delimiters may be simply eliminated, without further inspecting their contents. Then, it is possible to inject HTML tags, which will be included in the generated page, completely bypassing existing sanitization routines. Let’s consider a concrete example. Suppose we have a node containing some text that will be displayed back to the user. $HTMLCode Then, an attacker can provide the following input: $HTMLCode = script]]>alert(‘xss’)/script]]> and obtain the following node: script]]>alert(‘xss’)/ script]]> During the processing, the CDATA section delimiters are eliminated, generating the following HTML code: alert(‘XSS’) The result is that the application is vulnerable to XSS. External Entity: The set of valid entities can be extended by defining new entities. If the definition of an entity is a URI, the entity is called an external entity. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems. This behavior exposes the application to XML eXternal Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems. To test for XXE vulnerabilities, one can use the following input: ]>&xxe; This test could crash the web server (on a UNIX system), if the XML parser attempts to substitute the entity with the contents of the /dev/ random file. Other useful tests are the following: ]>&xxe; ]>&xxe; ]>&xxe; ]>&xxe; Tag Injection Once the first step is accomplished, the tester will have some information about the structure of the XML document. Then, it is possible to try to inject XML data and tags. We will show an example of how this can lead to a privilege escalation attack. Let’s considering the previous application. By inserting the following values: Username: tony Password: Un6R34kb!e E-mail: s4tan@hell.com0s4tan@hell.com the application will build a new node and append it to the XML database: gandalf !c3 0 gandalf@middleearth.com Stefan0 w1s3c 500 Stefan0@whysec.hmm tony Un6R34kb!e 500 s4tan@hell.com0s4tan@hell.com The resulting XML file is well formed. Furthermore, it is likely that, for the user tony, the value associated with the userid tag is the one appearing last, i.e., 0 (the admin ID). In other words, we have injected a user with administrative privileges. The only problem is that the userid tag appears twice in the last user node. Often, XML documents are associated with a schema or a DTD and will be rejected if they don’t comply with it. Let’s suppose that the XML document is specified by the following DTD: ]> Note that the userid node is defined with cardinality 1. In this case, the attack we have shown before (and other simple attacks) will not work, if the XML document is validated against its DTD before any processing occurs. However, this problem can be solved, if the tester controls the value of some nodes preceding the offending node (userid, in this example). In fact, the tester can comment out such node, by injecting a comment start/end sequence: Username: tony Password: Un6R34kb!e0s4tan@hell.com In this case, the final XML database is: gandalf !c3 0 gandalf@middleearth.com Stefan0 w1s3c 500 Stefan0@whysec.hmm tony Un6R34kb!e0s4tan@hell.com The original userid node has been commented out, leaving only the injected one. The document now complies with its DTD rules. Tools • XML Injection Fuzz Strings (from wfuzz tool) - https:/wfuzz.googlecode.com/svn/trunk/wordlist/Injections/XML.txt References Whitepapers • Alex Stamos: “Attacking Web Services” - http:/www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services. ppt • Gregory Steuck, “XXE (Xml eXternal Entity) attack”, http:/www.securityfocus.com/archive/1/297714 Testing for SSI Injection (OTG-INPVAL-009) Summary Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by the Server-Side Includes (SSI). In SSI injection testing, we test if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution. Server-Side Includes are directives that the web server parses before
135 136 Web Application Penetration Testing Web Application Penetration Testing serving the page to the user. They represent an alternative to writing CGI programs or embedding code using server-side scripting languages, when there’s only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables, and to execute external CGI scripts or system commands. Putting an SSI directive into a static HTML document is as easy as writing a piece of code like the following: we could guess if SSI are supported just by looking at the content of the target web site. If it contains .shtml files, then SSI are probably supported, as this extension is used to identify pages containing these directives. Unfortunately, the use of the shtml extension is not mandatory, so not having found any shtml files doesn’t necessarily mean that the target is not prone to SSI injection attacks. The next step consists of determining if an SSI injection attack is actually possible and, if so, what are the input points that we can use to inject our malicious code. [2] Where user input, cookie content and HTTP headers are handled. The complete list of input vectors is then quickly determined. [3] How the input is handled, what kind of filtering is performed, what characters the application is not letting through, and how many types of encoding are taken into account. Performing these steps is mostly a matter of using grep to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on). unlike SQL, no ACLs are enforced, as our query can access every part of the XML document. How to Test The XPath attack pattern was first published by Amit Klein [1] and is very similar to the usual SQL Injection.In order to get a first grasp of the problem, let’s imagine a login page that manages the authentication to an application in which the user must enter his/her username and password.Let’s assume that our database is represented by the following XML file: to print out the current time. to include the output of a CGI script. to include the content of a file or list files in a directory. to include the output of a system command. Then, if the web server’s SSI support is enabled, the server will parse these directives. In the default configuration, usually, most web servers don’t allow the use of the exec directive to execute system commands. As in every bad input validation situation, problems arise when the user of a web application is allowed to provide data that makes the application or the web server behave in an unforeseen manner. With regard to SSI injection, the attacker could provide input that, if inserted by the application (or maybe directly by the server) into a dynamically generated page, would be parsed as one or more SSI directives. This is a vulnerability very similar to a classical scripting language injection vulnerability. One mitigation is that the web server needs to be configured to allow SSI. On the other hand, SSI injection vulnerabilities are often simpler to exploit, since SSI directives are easy to understand and, at the same time, quite powerful, e.g., they can output the content of files and execute system commands. How to Test Black Box testing The first thing to do when testing in a Black Box fashion is finding if the web server actually supports SSI directives. Often, the answer is yes, as SSI support is quite common. To find out we just need to discover which kind of web server is running on our target, using classic information gathering techniques. Whether we succeed or not in discovering this piece of information, The testing activity required to do this is exactly the same used to test for other code injection vulnerabilities. In particular, we need to find every page where the user is allowed to submit some kind of input, and verify whether the application is correctly validating the submitted input. If sanitization is insufficient, we need to test if we can provide data that is going to be displayed unmodified (for example, in an error message or forum post). Besides common user-supplied data, input vectors that should always be considered are HTTP request headers and cookies content, since they can be easily forged. Once we have a list of potential injection points, we can check if the input is correctly validated and then find out where the provided input is stored. We need to make sure that we can inject characters used in SSI directives: < ! # = / . “ - > and [a-zA-Z0-9] To test if validation is insufficient, we can input, for example, a string like the following in an input form: This is similar to testing for XSS vulnerabilities using alert(“XSS”) If the application is vulnerable, the directive is injected and it would be interpreted by the server the next time the page is served, thus including the content of the Unix standard password file. The injection can be performed also in HTTP headers, if the web application is going to use that data to build a dynamically generated page: GET / HTTP/1.0 Referer: User-Agent: Gray Box testing If we have access to the application source code, we can quite easily find out: [1] If SSI directives are used. If they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate. Tools • Web Proxy Burp Suite - http:/portswigger.net • Paros - http:/www.parosproxy.org/index.shtml • WebScarab • String searcher: grep - http:/www.gnu.org/software/grep References Whitepapers • Apache Tutorial: “Introduction to Server Side Includes” - http:/httpd.apache.org/docs/1.3/howto/ssi.html • Apache: “Module mod_include” - http:/httpd.apache.org/ docs/1.3/mod/mod_include.html • Apache: “Security Tips for Server Configuration” - http:/httpd. apache.org/docs/1.3/misc/security_tips.html#ssi • Header Based Exploitation - http:/www.cgisecurity.net/papers/ header-based-exploitation.txt • SSI Injection instead of JavaScript Malware - http:/ jeremiahgrossman.blogspot.com/2006/08/ssi-injection-insteadof-javascript.html • IIS: “Notes on Server-Side Includes (SSI) syntax” - http:/blogs. iis.net/robert_mcmurray/archive/2010/12/28/iis-notes-on-serverside-includes-ssi-syntax-kb-203064-revisited.aspx Testing for XPath Injection (OTG-INPVAL-010) Summary XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test if it is possible to inject XPath syntax into a request interpreted by the application, allowing an attacker to execute user-controlled XPath queries.When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization. Web applications heavily use databases to store and access the data they need for their operations.Historically, relational databases have been by far the most common technology for data storage, but, in the last years, we are witnessing an increasing popularity for databases that organize data using the XML language. Just like relational databases are accessed via SQL language, XML databases use XPath as their standard query language. Since, from a conceptual point of view, XPath is very similar to SQL in its purpose and applications, an interesting result is that XPath injection attacks follow the same logic as SQL Injection attacks. In some aspects, XPath is even more powerful than standard SQL, as its whole power is already present in its specifications, whereas a large number of the techniques that can be used in a SQL Injection attack depend on the characteristics of the SQL dialect used by the target database. This means that XPath injection attacks can be much more adaptable and ubiquitous.Another advantage of an XPath injection attack is that, gandalf !c3 admin Stefan0 w1s3c guest tony Un6R34kb!e guest An XPath query that returns the account whose username is “gandalf” and the password is “!c3” would be the following: string(/user[username/text()=’gandalf’ and password/text()=’!c3’]/account/text()) If the application does not properly filter user input, the tester will be able to inject XPath code and interfere with the query result. For instance, the tester could input the following values: Username: ‘ or ‘1’ = ‘1 Password: ‘ or ‘1’ = ‘1 Looks quite familiar, doesn’t it? Using these parameters, the query becomes: string(/user[username/text()=’’ or ‘1’ = ‘1’ and password/ text()=’’ or ‘1’ = ‘1’]/account/text()) As in a common SQL Injection attack, we have created a query that always evaluates to true, which means that the application will authenticate the user even if a username or a password have not been provided. And as in a common SQL Injection attack, with XPath injection, the first step is to insert a single quote (‘) in the field to be tested, intro-
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:
27 28 Web Application Penetration T
Page 17 and 18: 31 32 Web Application Penetration T
Page 51 and 52: 99 100 Web Application Penetration
Page 67: 131 132 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?