4.0

More documents

Recommendations

Info

34 Web Application Penetration Testing 2. “robots.txt” saved as “www.google.com-robots.txt” 3. Sending Allow: URIs of www.google.com to web proxy i.e. 127.0.0.1:8080 /catalogs/about sent /catalogs/p? sent /news/directory sent ... 4. Done. cmlh$ Analyze robots.txt using Google Webmaster Tools Web site owners can use the Google “Analyze robots.txt” function to analyse the website as part of its “Google Webmaster Tools” (https:/ www.google.com/webmasters/tools). This tool can assist with testing and the procedure is as follows: 1. Sign into Google Webmaster Tools with a Google account. 2. On the dashboard, write the URL for the site to be analyzed. 3. Choose between the available methods and follow the on screen instruction. META Tag tags are located within the HEAD section of each HTML Document and should be consistent across a web site in the likely event that the robot/spider/crawler start point does not begin from a document link other than webroot i.e. a “deep link”[5]. If there is no “” entry then the “Robots Exclusion Protocol” defaults to “INDEX,FOLLOW” respectively. Therefore, the other two valid entries defined by the “Robots Exclusion Protocol” are prefixed with “NO...” i.e. “NOINDEX” and “NOFOLLOW”. Web spiders/robots/crawlers can intentionally ignore the “
35 Web Application Penetration Testing where. This may happen either by error (due to misconfigurations), or intentionally (for example, unadvertised administrative interfaces). To address these issues, it is necessary to perform web application discovery. Test Objectives Enumerate the applications within scope that exist on a web server How to Test Black Box Testing Web application discovery is a process aimed at identifying web applications on a given infrastructure. The latter is usually specified as a set of IP addresses (maybe a net block), but may consist of a set of DNS symbolic names or a mix of the two. This information is handed out prior to the execution of an assessment, be it a classic-style penetration test or an application-focused assessment. In both cases, unless the rules of engagement specify otherwise (e.g., “test only the application located at the URL http: /www.example.com/”), the assessment should strive to be the most comprehensive in scope, i.e. it should identify all the applications accessible through the given target. The following examples examine a few techniques that can be employed to achieve this goal. Note: Some of the following techniques apply to Internet-facing web servers, namely DNS and reverse-IP web-based search services and the use of search engines. Examples make use of private IP addresses (such as 192.168.1.100), which, unless indicated otherwise, represent generic IP addresses and are used only for anonymity purposes. There are three factors influencing how many applications are related to a given DNS name (or an IP address): 1. Different base URL The obvious entry point for a web application is www.example. com, i.e., with this shorthand notation we think of the web application originating at http: /www.example.com/ (the same applies for https). However, even though this is the most common situation, there is nothing forcing the application to start at “/”. For example, the same symbolic name may be associated to three web applications such as: http: /www.example.com/url1 http: / www.example.com/url2 http: /www.example.com/url3 In this case, the URL http: /www.example.com/ would not be associated with a meaningful page, and the three applications would be “hidden”, unless the tester explicitly knows how to reach them, i.e., the tester knows url1, url2 or url3. There is usually no need to publish web applications in this way, unless the owner doesn’t want them to be accessible in a standard way, and is prepared to inform the users about their exact location. This doesn’t mean that these applications are secret, just that their existence and location is not explicitly advertised. 2. Non-standard ports While web applications usually live on port 80 (http) and 443 (https), there is nothing magic about these port numbers. In fact, web applications may be associated with arbitrary TCP ports, and can be referenced by specifying the port number as follows: http[s]: /www. example.com:port/. For example, http: /www.example.com:20000/. 3. Virtual hosts DNS allows a single IP address to be associated with one or more symbolic names. For example, the IP address 192.168.1.100 might be associated to DNS names www.example.com, helpdesk.example. com, webmail.example.com. It is not necessary that all the names belong to the same DNS domain. This 1-to-N relationship may be reflected to serve different content by using so called virtual hosts. The information specifying the virtual host we are referring to is embedded in the HTTP 1.1 Host: header [1]. One would not suspect the existence of other web applications in addition to the obvious www.example.com, unless they know of helpdesk.example.com and webmail.example.com. Approaches to address issue 1 - non-standard URLs There is no way to fully ascertain the existence of non-standardnamed web applications. Being non-standard, there is no fixed criteria governing the naming convention, however there are a number of techniques that the tester can use to gain some additional insight. First, if the web server is mis-configured and allows directory browsing, it may be possible to spot these applications. Vulnerability scanners may help in this respect. Second, these applications may be referenced by other web pages and there is a chance that they have been spidered and indexed by web search engines. If testers suspect the existence of such “hidden” applications on www.example.com they could search using the site operator and examining the result of a query for “site: www.example. com”. Among the returned URLs there could be one pointing to such a non-obvious application. Another option is to probe for URLs which might be likely candidates for non-published applications. For example, a web mail front end might be accessible from URLs such as https:/www.example.com/webmail, https:/webmail.example.com/, or https:/mail.example.com/. The same holds for administrative interfaces, which may be published at hidden URLs (for example, a Tomcat administrative interface), and yet not referenced anywhere. So doing a bit of dictionary-style searching (or “intelligent guessing”) could yield some results. Vulnerability scanners may help in this respect. Approaches to address issue 2 - non-standard ports It is easy to check for the existence of web applications on non-standard ports. A port scanner such as nmap [2] is capable of performing service recognition by means of the -sV option, and will identify http[s] services on arbitrary ports. What is required is a full scan of the whole 64k TCP port address space. For example, the following command will look up, with a TCP connect scan, all open ports on IP 192.168.1.100 and will try to determine what services are bound to them (only essential switches are shown – nmap features a broad set of options, whose discussion is out of scope): nmap –PN –sT –sV –p0-65535 192.168.1.100 It is sufficient to examine the output and look for http or the indication of SSL-wrapped services (which should be probed to confirm that they are https). For example, the output of the previous command coullook like:
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 35: 33 Web Application Penetration Test
Page 87 and 88:
85 Web Application Penetration Test
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

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

Delete template?

Save as template?