4.0

More documents

Recommendations

Info

92 Web Application Penetration Testing which public documents a registered user downloads) it is essential that a different Session ID is used. The Session ID should therefore be monitored as the client switches from the secure to non-secure elements to ensure a different one is used. Result Expected: Every time the authentication is successful, the user should expect to receive: • A different session token • A token sent via encrypted channel every time they make an HTTP Request Testing for Proxies & Caching vulnerabilities: Proxies must also be considered when reviewing application security. In many cases, clients will access the application through corporate, ISP, or other proxies or protocol aware gateways (e.g., Firewalls). The HTTP protocol provides directives to control the behavior of downstream proxies, and the correct implementation of these directives should also be assessed. In general, the Session ID should never be sent over unencrypted transport and should never be cached. The application should be examined to ensure that encrypted communications are both the default and enforced for any transfer of Session IDs. Furthermore, whenever the Session ID is passed, directives should be in place to prevent its caching by intermediate and even local caches. The application should also be configured to secure data in caches over both HTTP/1.0 and HTTP/1.1 – RFC 2616 discusses the appropriate controls with reference to HTTP. HTTP/1.1 provides a number of cache control mechanisms. Cache-Control: no-cache indicates that a proxy must not re-use any data. Whilst Cache-Control: Private appears to be a suitable directive, this still allows a non-shared proxy to cache data. In the case of web-cafes or other shared systems, this presents a clear risk. Even with single-user workstations the cached Session ID may be exposed through a compromise of the file-system or where network stores are used. HTTP/1.0 caches do not recognise the Cache-Control: no-cache directive. Result Expected: The “Expires: 0” and Cache-Control: max-age=0 directives should be used to further ensure caches do not expose the data. Each request/response passing Session ID data should be examined to ensure appropriate cache directives are in use. Testing for GET & POST vulnerabilities: In general, GET requests should not be used, as the Session ID may be exposed in Proxy or Firewall logs. They are also far more easily manipulated than other types of transport, although it should be noted that almost any mechanism can be manipulated by the client with the right tools. Furthermore, Cross-site Scripting (XSS) attacks are most easily exploited by sending a specially constructed link to the victim. This is far less likely if data is sent from the client as POSTs. Result Expected: All server side code receiving data from POST requests should be tested to ensure it does not accept the data if sent as a GET. For example, consider the following POST request generated by a log in page. POST http:/owaspapp.com/login.asp HTTP/1.1 Host: owaspapp.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Paros/3.0.2b Accept: */* Accept-Language: en-us, en Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG Cache-Control: max-age=0 Content-Type: application/x-www-form-urlencoded Content-Length: 34 Login=Username&password=Password&SessionID=12345678 If login.asp is badly implemented, it may be possible to log in using the following URL: http: /owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678 Potentially insecure server-side scripts may be identified by checking each POST in this way. Testing for Transport vulnerabilities: All interaction between the Client and Application should be tested at least against the following criteria. • How are Session IDs transferred? e.g., GET, POST, Form Field (including hidden fields) • Are Session IDs always sent over encrypted transport by default? • Is it possible to manipulate the application to send Session IDs unencrypted? e.g., by changing HTTP to HTTPS? • What cache-control directives are applied to requests/responses passing Session IDs? • Are these directives always present? If not, where are the exceptions? • Are GET requests incorporating the Session ID used? • If POST is used, can it be interchanged with GET? References Whitepapers • RFCs 2109 & 2965 – HTTP State Management Mechanism [D. Kristol, L. Montulli] - http: /www.ietf.org/rfc/rfc2965.txt, http: /www.ietf.org/rfc/rfc2109.txt • RFC 2616 – Hypertext Transfer Protocol - HTTP/1.1 - http: /www.ietf.org/rfc/rfc2616.txt Testing for CSRF (OTG-SESS-005) Summary CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email or chat), an attacker may force the users of a web application to execute actions of the attacker’s choosing. A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application. CSRF relies on the following: [1] Web browser behavior regarding the handling of session-re-
93 Web Application Penetration Testing lated information such as cookies and http authentication information; [2] Knowledge by the attacker of valid web application URLs; [3] Application session management relying only on information which is known by the browser; [4] Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag img. Points 1, 2, and 3 are essential for the vulnerability to be present, while point 4 is accessory and facilitates the actual exploitation, but is not strictly required. Point 1) Browsers automatically send information which is used to identify a user session. Suppose site is a site hosting a web application, and the user victim has just authenticated himself to site. In response, site sends victim a cookie which identifies requests sent by victim as belonging to victim’s authenticated session. Basically, once the browser receives the cookie set by site, it will automatically send it along with any further requests directed to site. Point 2) If the application does not make use of session-related information in URLs, then it means that the application URLs, their parameters, and legitimate values may be identified (either by code analysis or by accessing the application and taking note of forms and URLs embedded in the HTML/JavaScript). Point 3) ”Known by the browser” refers to information such as cookies, or http-based authentication information (such as Basic Authentication; and not form-based authentication), which are stored by the browser and subsequently resent at each request directed towards an application area requesting that authentication. The vulnerabilities discussed next apply to applications which rely entirely on this kind of information to identify a user session. Suppose, for simplicity’s sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If victim has already authenticated himself, submitting another request causes the cookie to be automatically sent with it (see picture, where the user accesses an application on www.example.com). The GET request could be originated in several different ways: • by the user, who is using the actual web application; • by the user, who types the URL directly in the browser; • by the user, who follows a link (external to the application) pointing to the URL. These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There are a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email message, or appear in a malicious web site where the user is lured, i.e., the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the application. If the user clicks on the link, since it was already authenticated by the web application on site, the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application and probably not what the user expects to happen. Think of a malicious link causing a fund transfer on a web banking application to appreciate the implications. By using a tag such as img, as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing him to visit an URL referring to a page containing the following (oversimplified) HTML: ... ... What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well. This results in a request being automatically sent to the web application hosted on site. It is not important that the image URL does not refer to a proper image, its presence will trigger the request specified in the src field anyway. This happens provided that image download is not disabled in the browsers, which is a typical configuration since disabling images would cripple most web applications beyond usability. The problem here is a consequence of the following facts: • there are HTML tags whose appearance in a page result in automatic http request execution (img being one of those); • the browser has no way to tell that the resource referenced by img is not actually an image and is in fact not legitimate; • image loading happens regardless of the location of the alleged image, i.e., the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications. It is the fact that HTML content unrelated to the web application may refer components in the application, and the fact that the browser automatically composes a valid request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information related to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs impossible. The problem might be even worse, since in integrated mail/
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: 41 Web Application Penetration Test
Page 93: 91 Web Application Penetration Test
Page 103 and 104: 101 Web Application Penetration Tes
Page 145 and 146:
143 Web Application Penetration Tes
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?