4.0

More documents

Recommendations

Info

38 Web Application Penetration Testing Check HTML version information for valid version numbers and Data Type Definition (DTD) URLs will advise robots to not index and not follow links on the HTML page containing the tag. • “strict.dtd” -- default strict DTD • “loose.dtd” -- loose DTD • “frameset.dtd” -- DTD for frameset documents Some Meta tags do not provide active attack vectors but instead allow an attacker to profile an application to Some Meta tags alter HTTP response headers, such as http-equiv that sets an HTTP response header based on the the content attribute of a meta element, such as: which will result in the HTTP header: and Expires: Fri, 21 Dec 2012 12:34:56 GMT will result in Cache-Control: no-cache Test to see if this can be used to conduct injection attacks (e.g. CRLF attack). It can also help determine the level of data leakage via the browser cache. A common (but not WCAG compliant) Meta tag is the refresh. A common use for Meta tag is to specify keywords that a search engine may use to improve the quality of search results. Although most web servers manage search engine indexing via the robots.txt file, it can also be managed by Meta tags. The tag below The Platform for Internet Content Selection (PICS) and Protocol for Web Description Resources (POWDER) provide infrastructure for associating meta data with Internet content. Gray Box Testing Not applicable. Tools • Wget • Browser “view source” function • Eyeballs • Curl References Whitepapers [1] http:/www.w3.org/TR/1999/REC-html401-19991224 HTML version <strong>4.0</strong>1 [2] http:/www.w3.org/TR/2010/REC-xhtml-basic-20101123/ XHT- ML (for small devices) [3] http:/www.w3.org/TR/html5/ HTML version 5 Identify application entry points (OTG-INFO-006) Summary Enumerating the application and its attack surface is a key precursor before any thorough testing can be undertaken, as it allows the tester to identify likely areas of weakness. This section aims to help identify and map out areas within the application that should be investigated once enumeration and mapping have been completed. Test Objectives Understand how requests are formed and typical responses from the application How to Test Before any testing begins, the tester should always get a good understanding of the application and how the user and browser communicates with it. As the tester walks through the application, they should pay special attention to all HTTP requests (GET and POST Methods, also known as Verbs), as well as every parameter and form field that is passed to the application. In addition, they should pay attention to when GET requests are used and when POST requests are used to pass parameters to the application. It is very common that GET requests are used, but when sensitive information is passed, it is often done within the body of a POST request. Note that to see the parameters sent in a POST request, the tester will need to use a tool such as an intercepting proxy (for example, OWASP: Zed Attack Proxy (ZAP)) or a browser plug-in. Within the POST request, the tester should also make special note of any hidden form fields that are being passed to the application, as these usually contain sensitive information, such as state information, quantity of items, the price of items, that the developer never intended for you to see or change.
39 Web Application Penetration Testing In the author’s experience, it has been very useful to use an intercepting proxy and a spreadsheet for this stage of the testing. The proxy will keep track of every request and response between the tester and the application as they u walk through it. Additionally, at this point, testers usually trap every request and response so that they can see exactly every header, parameter, etc. that is being passed to the application and what is being returned. This can be quite tedious at times, especially on large interactive sites (think of a banking application). However, experience will show what to look for and this phase can be significantly reduced. As the tester walks through the application, they should take note of any interesting parameters in the URL, custom headers, or body of the requests/responses, and save them in a spreadsheet. The spreadsheet should include the page requested (it might be good to also add the request number from the proxy, for future reference), the interesting parameters, the type of request (POST/GET), if access is authenticated/unauthenticated, if SSL is used, if it’s part of a multi-step process, and any other relevant notes. Once they have every area of the application mapped out, then they can go through the application and test each of the areas that they have identified and make notes for what worked and what didn’t work. The rest of this guide will identify how to test each of these areas of interest, but this section must be undertaken before any of the actual testing can commence. Below are some points of interests for all requests and responses. Within the requests section, focus on the GET and POST methods, as these appear the majority of the requests. Note that other methods, such as PUT and DELETE, can be used. Often, these more rare requests, if allowed, can expose vulnerabilities. There is a special section in this guide dedicated for testing these HTTP methods. Requests: • Identify where GETs are used and where POSTs are used. • Identify all parameters used in a POST request (these are in the body of the request). • Within the POST request, pay special attention to any hidden parameters. When a POST is sent all the form fields (including hidden parameters) will be sent in the body of the HTTP message to the application. These typically aren’t seen unless a proxy or view the HTML source code is used. In addition, the next page shown, its data, and the level of access can all be different depending on the value of the hidden parameter(s). • Identify all parameters used in a GET request (i.e., URL), in particular the query string (usually after a ? mark). • Identify all the parameters of the query string. These usually are in a pair format, such as foo=bar. Also note that many parameters can be in one query string such as separated by a &, ~, :, or any other special character or encoding. • A special note when it comes to identifying multiple parameters in one string or within a POST request is that some or all of the parameters will be needed to execute the attacks. The tester needs to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application. Later sections of the guide will identify how to test these parameters. At this point, just make sure each one of them is identified. • Also pay attention to any additional or custom type headers not typically seen (such as debug=False). Responses: • Identify where new cookies are set (Set-Cookie header), modified, or added to. • Identify where there are any redirects (3xx HTTP status code), 400 status codes, in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e., unmodified requests). • Also note where any interesting headers are used. For example, “Server: BIG-IP” indicates that the site is load balanced. Thus, if a site is load balanced and one server is incorrectly configured, then the tester might have to make multiple requests to access the vulnerable server, depending on the type of load balancing used. Black Box Testing Testing for application entry points: The following are two examples on how to check for application entry points. EXAMPLE 1 This example shows a GET request that would purchase an item from an online shopping application. GET https:/x.x.x.x/shoppingApp/buyme.asp?CUSTOME- RID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x Host: x.x.x.x Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuY- W1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy Result Expected: Here the tester would note all the parameters of the request such as CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just be encoded parameters or used for session state). EXAMPLE 2 This example shows a POST request that would log you into an application. POST https:/x.x.x.x/KevinNotSoGoodApp/authenticate.asp?- service=login Host: x.x.x.x Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCB- zZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaX- MgMTIzNA== CustomCookie=00my00trusted00ip00is00x.x.x.x00 Body of the POST message: user=admin&pass=pass123&debug=true&fromtrustIP=true Result Expected: In this example the tester would note all the parameters as they have before but notice that the parameters are passed in the body of the message and not in the URL. Additionally, note that there is a custom cookie that is being used.
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 39: 37 Web Application Penetration Test
Page 91 and 92:
89 Web Application Penetration Test
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?