4.0

More documents

Recommendations

Info

138Web Application Penetration TestingThis is similar to testing for XSS vulnerabilities usingalert(“XSS”)If the application is vulnerable, the directive is injected and it wouldbe interpreted by the server the next time the page is served, thusincluding the content of the Unix standard password file.The injection can be performed also in HTTP headers, if the webapplication is going to use that data to build a dynamically generatedpage:GET / HTTP/1.0Referer: User-Agent: Gray Box testingIf we have access to the application source code, we can quiteeasily find out:[1] If SSI directives are used. If they are, then the web server isgoing to have SSI support enabled, making SSI injection at leasta potential issue to investigate.[2] Where user input, cookie content and HTTP headers arehandled. The complete list of input vectors is then quicklydetermined.[3] How the input is handled, what kind of filtering is performed,what characters the application is not letting through, and howmany types of encoding are taken into account.Performing these steps is mostly a matter of using grep to findthe right keywords inside the source code (SSI directives, CGI environmentvariables, 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/grepReferencesWhitepapers• 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.aspxTesting for XPath Injection (OTG-INPVAL-010)SummaryXPath is a language that has been designed and developed primarilyto address parts of an XML document. In XPath injectiontesting, we test if it is possible to inject XPath syntax into a requestinterpreted by the application, allowing an attacker to executeuser-controlled XPath queries.When successfully exploited,this vulnerability may allow an attacker to bypass authenticationmechanisms or access information without proper authorization.Web applications heavily use databases to store and access thedata they need for their operations.Historically, relational databaseshave been by far the most common technology for data storage,but, in the last years, we are witnessing an increasing popularityfor databases that organize data using the XML language.Just like relational databases are accessed via SQL language, XMLdatabases use XPath as their standard query language.Since, from a conceptual point of view, XPath is very similar to SQLin its purpose and applications, an interesting result is that XPathinjection attacks follow the same logic as SQL Injection attacks. Insome aspects, XPath is even more powerful than standard SQL, asits whole power is already present in its specifications, whereas alarge number of the techniques that can be used in a SQL Injectionattack depend on the characteristics of the SQL dialect used bythe target database. This means that XPath injection attacks canbe much more adaptable and ubiquitous.Another advantage of anXPath injection attack is that, unlike SQL, no ACLs are enforced, asour query can access every part of the XML document.How to TestThe XPath attack pattern was first published by Amit Klein [1]and is very similar to the usual SQL Injection.In order to get a firstgrasp of the problem, let’s imagine a login page that manages theauthentication to an application in which the user must enter his/her username and password.Let’s assume that our database isrepresented by the following XML file:gandalf!c3adminStefan0w1s3cguesttonyUn6R34kb!eguestAn XPath query that returns the account whose username is “gandalf”and the password is “!c3” would be the following:
139Web Application Penetration Testingstring( /user[username/text()=’gandalf’ and password/text()=’!c3’]/account/text())If the application does not properly filter user input, the tester willbe able to inject XPath code and interfere with the query result.For instance, the tester could input the following values:Username: ‘ or ‘1’ = ‘1Password: ‘ or ‘1’ = ‘1front-end web servers.Therefore, mail server results may be morevulnerable to attacks by end users (see the scheme presented inFigure 1).WEBMAIL USER1Looks quite familiar, doesn’t it? Using these parameters, the querybecomes:string( /user[username/text()=’’ or ‘1’ = ‘1’ and password/text()=’’ or ‘1’ = ‘1’]/account/text())INTERNETAs in a common SQL Injection attack, we have created a querythat always evaluates to true, which means that the applicationwill authenticate the user even if a username or a password havenot been provided. And as in a common SQL Injection attack, withXPath injection, the first step is to insert a single quote (‘) in thefield to be tested, introducing a syntax error in the query, and tocheck whether the application returns an error message.If there is no knowledge about the XML data internal details and if theapplication does not provide useful error messages that help us reconstructits internal logic, it is possible to perform a Blind XPath Injectionattack, whose goal is to reconstruct the whole data structure.The technique is similar to inference based SQL Injection, as theapproach is to inject code that creates a query that returns one bitof information. Blind XPath Injection is explained in more detail byAmit Klein in the referenced paper.ReferencesWhitepapers• Amit Klein: “Blind XPath Injection” -http://www.modsecurity.org/archive/amit/blind-xpathinjection.pdf• XPath 1.0 specifications - http: /www.w3.org/TR/xpathTesting for IMAP/SMTP Injection(OTG-INPVAL-011)SummaryThis threat affects all applications that communicate with mailservers (IMAP/SMTP), generally webmail applications. The aim ofthis test is to verify the capacity to inject arbitrary IMAP/SMTPcommands into the mail servers, due to input data not being properlysanitized.The IMAP/SMTP Injection technique is more effective if the mailserver is not directly accessible from Internet. Where full communicationwith the backend mail server is possible, it is recommendedto conduct direct testing.An IMAP/SMTP Injection makes it possible to access a mail serverwhich otherwise would not be directly accessible from the Internet.In some cases, these internal systems do not have the samelevel of infrastructure security and hardening that is applied to thePUBLIC ZONE2WEBMAIL APPLICATION2 3PRIVATE ZONE (HIDDEN SERVERS)MAIL SERVERSFigure 1 depicts the flow of traffic generally seen when usingwebmail technologies. Step 1 and 2 is the user interacting withthe webmail client, whereas step 2 is the tester bypassing thewebmail client and interacting with the back-end mail serversdirectly.This technique allows a wide variety of actions and attacks. Thepossibilities depend on the type and scope of injection and themail server technology being tested.Some examples of attacks using the IMAP/SMTP Injection techniqueare:
Page 1 and 2:
1Testing Guide4.0Project Leaders: M
Page 3 and 4:
Testing Guide Foreword - Table of c
Page 5 and 6:
3Testing Guide Foreword - Table of
Page 7 and 8:
5Testing Guide Foreword - By Eoin K
Page 9 and 10:
7Testing Guide Frontispiece1Testing
Page 11 and 12:
9Testing Guide Introduction2The OWA
Page 13 and 14:
11Testing Guide Introductionvide en
Page 15 and 16:
13Testing Guide IntroductionTesting
Page 17 and 18:
15Testing Guide Introductionlaid on
Page 19 and 20:
17Testing Guide Introductionvalidat
Page 21 and 22:
19Testing Guide IntroductionUSERthe
Page 23 and 24:
21Testing Guide Introductionment wh
Page 25 and 26:
23Testing Guide Introductionoffendi
Page 27 and 28:
25The OWASP Testing Frameworksectio
Page 29 and 30:
27Web Application Penetration Testi
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: 87Web Application Penetration Testi
Page 103 and 104: 101Web Application Penetration Test
Page 139: 137Web Application Penetration Test
Page 191 and 192:
189Web Application Penetration Test
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:
209same code can be applied to sess
Page 213 and 214:
211ReportingTest IDLowest versionIn
Page 215 and 216:
213ReportingTest IDBusiness Logic T
Page 217 and 218:
215Appendixkajfghlhfkcocafkcjlajldi
Page 219 and 220:
217AppendixTesting - http:/www.nist
Page 221 and 222:
219Cross Site Scripting (XSS)For de
Page 223 and 224:
221LDAP InjectionFor details on LDA
show all

4.0

Create successful ePaper yourself

Delete template?

Save as template?