4.0

More documents

Recommendations

Info

86 Web Application Penetration Testing fore vital in the overall security of the application. Being able to tamper with cookies may result in hijacking the sessions of legitimate users, gaining higher privileges in an active session, and in general influencing the operations of the application in an unauthorized way. In this test the tester has to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. The overall goal is to be able to forge a cookie that will be considered valid by the application and that will provide some kind of unauthorized access (session hijacking, privilege escalation, ...). Usually the main steps of the attack pattern are the following: • cookie collection: collection of a sufficient number of cookie samples; • cookie reverse engineering: analysis of the cookie generation algorithm; • cookie manipulation: forging of a valid cookie in order to perform the attack. This last step might require a large number of attempts, depending on how the cookie is created (cookie brute-force attack). Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here testers are not trying to recreate a perfectly valid cookie. Instead, the goal is to overflow a memory area, thereby interfering with the correct behavior of the application and possibly injecting (and remotely executing) malicious code. How to Test Black Box Testing and Examples All interaction between the client and application should be tested at least against the following criteria: • Are all Set-Cookie directives tagged as Secure? • Do any Cookie operations take place over unencrypted transport? • Can the Cookie be forced over unencrypted transport? • If so, how does the application maintain security? • Are any Cookies persistent? • What Expires= times are used on persistent cookies, and are they reasonable? • Are cookies that are expected to be transient configured as such? • What HTTP/1.1 Cache-Control settings are used to protect Cookies? • What HTTP/1.0 Cache-Control settings are used to protect Cookies? Cookie collection The first step required to manipulate the cookie is to understand how the application creates and manages cookies. For this task, testers have to try to answer the following questions: • How many cookies are used by the application? Surf the application. Note when cookies are created. Make a list of received cookies, the page that sets them (with the set-cookie directive), the domain for which they are valid, their value, and their characteristics. • Which parts of the the application generate and/or modify the cookie? Surfing the application, find which cookies remain constant and which get modified. What events modify the cookie? • Which parts of the application require this cookie in order to be accessed and utilized? Find out which parts of the application need a cookie. Access a page, then try again without the cookie, or with a modified value of it. Try to map which cookies are used where. A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase. Session Analysis The session tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage. • Token Structure & Information Leakage The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side. If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following: http: /foo.bar/showImage?img=img00011 If part or the entire token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation. For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash: Hex Base64 MD5 3139322E3136382E3130302E313A6F77617370757 365723A70617373776F72643A31353A3538 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6c GFzc3dvcmQ6MTU6NTg= 01c2fc4f0a817afd8366689bd29dd40a Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised. Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following: owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412 Having analyzed a single session token, the representative sample should be examined. A simple analysis of the tokens should immediately reveal any obvious patterns. For example, a 32 bit token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address. If the second
87 Web Application Penetration Testing 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation. See examples. If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, log in attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token. The following areas should be addressed during the single and multiple Session ID structure testing: • What parts of the Session ID are static? • What clear-text confidential information is stored in the Session D? E.g. usernames/UID, IP addresses • What easily decoded confidential information is stored? • What information can be deduced from the structure of the Session ID? • What portions of the Session ID are static for the same log in conditions? • What obvious patterns are present in the Session ID as a whole, or individual portions? Session ID Predictability and Randomness Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns. These analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools to deduce any patterns in the Session ID content. Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed. Variable elements should be analyzed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo-random elements. Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable. In analyzing Session ID sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application. • Are the Session IDs provably random in nature? Can the resulting values be reproduced? • Do the same input conditions produce the same ID on a subsequent run? • Are the Session IDs provably resistant to statistical or cryptanalysis? • What elements of the Session IDs are time-linked? • What portions of the Session IDs are predictable? • Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs? Cookie reverse engineering Now that the tester has enumerated the cookies and has a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies is the tester interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks. These characteristics are summarized below: [1] Unpredictability: a cookie must contain some amount of hardto-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user’s session. If an attacker can guess the cookie used in an active session of a legitimate user, they will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values and/or cryptography can be used. [2] Tamper resistance: a cookie must resist malicious attempts of modification. If the tester receives a cookie like IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value) [3] Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from the disk or memory afterwards to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel). [4] “Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping. The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if the tester needs to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information). It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies. A cookie collected before being authenticated can be very different from a cookie obtained after the authentication. Another aspect to keep into consideration is time. Always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a time stamp as part of the cookie value). The time recorded could be the local time or the server’s time stamp included in the HTTP response (or both). When analyzing the collected values, the tester should try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.
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: 35 Web Application Penetration Test
Page 87: 85 Web Application Penetration Test
Page 103 and 104: 101 Web Application Penetration Tes
Page 139 and 140:
137 Web Application Penetration Tes
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?