4.0

More documents

Recommendations

Info

138 Web Application Penetration Testing 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. [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). 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-injectioninstead-of-javascript.html • IIS: “Notes on Server-Side Includes (SSI) syntax” - http: /blogs. iis.net/robert_mcmurray/archive/2010/12/28/iis-notes-onserver-side-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, 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: 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:
139 Web Application Penetration Testing 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 front-end web servers.Therefore, mail server results may be more vulnerable to attacks by end users (see the scheme presented in Figure 1). WEBMAIL USER 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()) INTERNET 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, introducing a syntax error in the query, and to check whether the application returns an error message. If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us reconstruct its internal logic, it is possible to perform a Blind XPath Injection attack, whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information. Blind XPath Injection is explained in more detail by Amit Klein in the referenced paper. References Whitepapers • Amit Klein: “Blind XPath Injection” - http://www.modsecurity.org/archive/amit/blind-xpathinjection.pdf • XPath 1.0 specifications - http: /www.w3.org/TR/xpath Testing for IMAP/SMTP Injection (OTG-INPVAL-011) Summary This threat affects all applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not being properly sanitized. The IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from Internet. Where full communication with the backend mail server is possible, it is recommended to conduct direct testing. An IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible from the Internet. In some cases, these internal systems do not have the same level of infrastructure security and hardening that is applied to the PUBLIC ZONE 2 WEBMAIL APPLICATION 2 3 PRIVATE ZONE (HIDDEN SERVERS) MAIL SERVERS Figure 1 depicts the flow of traffic generally seen when using webmail technologies. Step 1 and 2 is the user interacting with the webmail client, whereas step 2 is the tester bypassing the webmail client and interacting with the back-end mail servers directly. This technique allows a wide variety of actions and attacks. The possibilities depend on the type and scope of injection and the mail server technology being tested. Some examples of attacks using the IMAP/SMTP Injection technique are:
Page 1 and 2:
1 Testing Guide 4.0 Project Leaders
Page 3 and 4:
Testing Guide Foreword - Table of c
Page 5 and 6:
3 Testing Guide Foreword - Table of
Page 7 and 8:
5 Testing Guide Foreword - By Eoin
Page 9 and 10:
7 Testing Guide Frontispiece 1 Test
Page 11 and 12:
9 Testing Guide Introduction 2 The
Page 13 and 14:
11 Testing Guide Introduction vide
Page 15 and 16:
13 Testing Guide Introduction Testi
Page 17 and 18:
15 Testing Guide Introduction laid
Page 19 and 20:
17 Testing Guide Introduction valid
Page 21 and 22:
19 Testing Guide Introduction USER
Page 23 and 24:
21 Testing Guide Introduction ment
Page 25 and 26:
23 Testing Guide Introduction offen
Page 27 and 28:
25 The OWASP Testing Framework sect
Page 29 and 30:
27 Web Application Penetration Test
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:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90: 87 Web Application Penetration Test
Page 103 and 104: 101 Web Application Penetration Tes
Page 139: 137 Web Application Penetration Tes
Page 191 and 192:
189 Web Application Penetration Tes
Page 193 and 194:
Page 195 and 196:
Page 197 and 198:
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
Page 211 and 212:
209 same code can be applied to ses
Page 213 and 214:
211 Reporting Test ID Lowest versio
Page 215 and 216:
213 Reporting Test ID Business Logi
Page 217 and 218:
215 Appendix kajfghlhfkcocafkcjlajl
Page 219 and 220:
217 Appendix Testing - http:/www.ni
Page 221 and 222:
219 Cross Site Scripting (XSS) For
Page 223 and 224:
221 LDAP Injection For details on L
show all

4.0

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

Delete template?

Save as template?