4.0

More documents

Recommendations

Info

28 Web Application Penetration Testing • Phase 2 Active mode: In this phase the tester begins to test using the methodology described in the follow sections. The set of active tests have been split into 11 sub-categories for a total of 91 controls: • Information Gathering • Configuration and Deployment Management Testing • Identity Management Testing • Authentication Testing • Authorization Testing • Session Management Testing • Input Validation Testing • Error Handling • Cryptography • Business Logic Testing • Client Side Testing Testing for Information Gathering Understanding the deployed configuration of the server hosting the web application is almost as important as the application security testing itself. After all, an application chain is only as strong as its weakest link. Application platforms are wide and varied, but some key platform configuration errors can compromise the application in the same way an unsecured application can compromise the server. Conduct search engine discovery/reconnaissance for information leakage (OTG-INFO-001) Summary There are direct and indirect elements to search engine discovery and reconnaissance. Direct methods relate to searching the indexes and the associated content from caches. Indirect methods relate to gleaning sensitive design and configuration information by searching forums, newsgroups, and tendering websites. Once a search engine robot has completed crawling, it commences indexing the web page based on tags and associated attributes, such as , in order to return the relevant search results [1]. If the robots. txt file is not updated during the lifetime of the web site, and inline HTML meta tags that instruct robots not to index content have not been used, then it is possible for indexes to contain web content not intended to be included in by the owners. Website owners may use the previously mentioned robots.txt, HTML meta tags, authentication, and tools provided by search engines to remove such content. Search operators Using the advanced “site:” search operator, it is possible to restrict search results to a specific domain [2]. Do not limit testing to just one search engine provider as they may generate different results depending on when they crawled content and their own algorithms. Consider using the following search engines: • Baidu • binsearch.info • Bing • Duck Duck Go • ixquick/Startpage • Google • Shodan • PunkSpider Duck Duck Go and ixquick/Startpage provide reduced information leakage about the tester. Google provides the Advanced “cache:” search operator [2], but this is the equivalent to clicking the “Cached” next to each Google Search Result. Hence, the use of the Advanced “site:” Search Operator and then clicking “Cached” is preferred. The Google SOAP Search API supports the doGetCachedPage and the associated doGetCachedPageResponse SOAP Messages [3] to assist with retrieving cached pages. An implementation of this is under development by the OWASP “Google Hacking” Project. PunkSpider is web application vulnerability search engine. It is of little use for a penetration tester doing manual work. However it can be useful as demonstration of easiness of finding vulnerabilities by script-kiddies. Example To find the web content of owasp.org indexed by a typical search engine, the syntax required is: site:owasp.org Test Objectives To understand what sensitive design and configuration information of the application/system/organization is exposed both directly (on the organization’s website) or indirectly (on a third party website). How to Test Use a search engine to search for: • Network diagrams and configurations • Archived posts and emails by administrators and other key staff • Log on procedures and username formats • Usernames and passwords • Error message content • Development, test, UAT and staging versions of the website To display the index.html of owasp.org as cached, the syntax is: cache:owasp.org
29 Web Application Penetration Testing Google Hacking Database The Google Hacking Database is list of useful search queries for Google. Queries are put in several categories: • Footholds • Files containing usernames • Sensitive Directories • Web Server Detection • Vulnerable Files • Vulnerable Servers • Error Messages • Files containing juicy info • Files containing passwords • Sensitive Online Shopping Info Tools [4] FoundStone SiteDigger: http:/www.mcafee.com/uk/downloads/ free-tools/sitedigger.aspx [5] Google Hacker: http:/yehg.net/lab/pr0js/files.php/googlehacker. zip [6] Stach & Liu’s Google Hacking Diggity Project: http:/www.stachliu.com/resources/tools/google-hacking-diggity-project/ [7] PunkSPIDER: http:/punkspider.hyperiongray.com/ References Web [1] “Google Basics: Learn how Google Discovers, Crawls, and Serves Web Pages” - https:/support.google.com/webmasters/answer/70897 [2] “Operators and More Search Help”: https:/support.google.com/ websearch/answer/136861?hl=en [3] “Google Hacking Database”: http:/www.exploit-db.com/google-dorks/ Remediation Carefully consider the sensitivity of design and configuration information before it is posted online. Periodically review the sensitivity of existing design and configuration information that is posted online. Fingerprint Web Server (OTG-INFO-002) Summary Web server fingerprinting is a critical task for the penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing. There are several different vendors and versions of web servers on the market today. Knowing the type of web server that is being tested significantly helps in the testing process and can also change the course of the test. This information can be derived by sending the web server specific commands and analyzing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely do different versions react the same to all HTTP commands. So by sending several different commands, the tester can increase the accuracy of their guess. Test Objectives Find the version and type of a running web server to determine known vulnerabilities and the appropriate exploits to use during testing. How to Test Black Box testing The simplest and most basic form of identifying a web server is to look at the Server field in the HTTP response header. Netcat is used in this experiment. Consider the following HTTP Request-Response: $ nc 202.41.76.251 80 HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Mon, 16 Jun 2003 02:53:29 GMT Server: Apache/1.3.3 (Unix) (Red Hat/Linux) Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT ETag: “1813-49b-361b4df6” Accept-Ranges: bytes Content-Length: 1179 Connection: close Content-Type: text/html From the Server field, one can understand that the server is likely Apache, version 1.3.3, running on Linux operating system. Four examples of the HTTP response headers are shown below. From an Apache 1.3.23 server: HTTP/1.1 200 OK Date: Sun, 15 Jun 2003 17:10: 49 GMT Server: Apache/1.3.23 Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT ETag: 32417-c4-3e5d8a83 Accept-Ranges: bytes Content-Length: 196 Connection: close Content-Type: text/HTML
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: 27 Web Application Penetration Test
Page 33 and 34: 31 Web Application Penetration Test
Page 81 and 82:
79 Web Application Penetration Test
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
101 Web Application Penetration Tes
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
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

Create successful ePaper yourself

Delete template?

Save as template?