4.0

More documents

Recommendations

Info

98 Web Application Penetration Testing the code must invoke the appropriate methods, e.g. HttpSession. invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker. References OWASP Resources • Session Management Cheat Sheet Testing for Session puzzling (OTG-SESS-008) Summary Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions, including by not limited to: • Bypass efficient authentication enforcement mechanisms, and impersonate legitimate users. • Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof. • Skip over qualifying phases in multi-phase processes, even if the process includes all the commonly recommended code level restrictions. • Manipulate server-side values in indirect methods that cannot be predicted or detected. • Execute traditional attacks in locations that were previously unreachable, or even considered secure. This vulnerability occurs when an application uses the same session variable for more than one purpose. An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another. For example, an attacker could use session variable overloading to bypass authentication enforcement mechanisms of applications that enforce authentication by validating the existence of session variables that contain identity–related values, which are usually stored in the session after a successful authentication process. This means an attacker first accesses a location in the application that sets session context and then accesses privileged locations that examine this context. For example - an authentication bypass attack vector could be executed by accessing a publicly accessible entry point (e.g. a password recovery page) that populates the session with an identical session variable, based on fixed values or on user originating input. How to Test Black Box Testing This vulnerability can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points and then examining exit points. In case of black box testing this procedure is difficult and requires some luck since every different sequence could lead to a different result. Examples A very simple example could be the password reset functionality that, in the entry point, could request the user to provide some identifying information such as the username or the e-mail address. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages in the application that show private data based on this session object. In this manner the attacker could bypass the authentication process. Gray Box testing The most effective way to detect these vulnerabilities is via a source code review. References Whitepapers • Session Puzzles: http: /puzzlemall.googlecode.com/files/Session%20Puzzles%20 -%20Indirect%20Application%20Attack%20Vectors%20-%20 May%202011%20-%20Whitepaper.pdf • Session Puzzling and Session Race Conditions: http: /sectooladdict.blogspot.com/2011/09/session-puzzlingand-session-race.html Remediation Session variables should only be used for a single consistent purpose. Input Validation Testing The most common web application security weakness is the failure to properly validate input coming from the client or from the environment before using it. This weakness leads to almost all of the major vulnerabilities in web applications, such as cross site scripting, SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows. Data from an external entity or client should never be trusted, since it can be arbitrarily tampered with by an attacker. “All Input is Evil”, says Michael Howard in his famous book “Writing Secure Code”. That is rule number one. Unfortunately, complex applications often have a large number of entry points, which makes it difficult for a developer to enforce this rule. This chapter describes Data Validation testing. This is the task of testing all the possible forms of input to understand if the application sufficiently validates input data before using it. Testing for Reflected Cross site scripting (OTG-INPVAL-001) Summary Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim. Reflected XSS are the most frequent type of XSS attacks found in the wild. Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also referred to as first-order or type 1 XSS.
99 Web Application Penetration Testing When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests back to the client. The common modus operandi of the attack includes a design step, in which the attacker creates and tests an offending URI, a social engineering step, in which she convinces her victims to load this URI on their browsers, and the eventual execution of the offending code using the victim’s browser. Commonly the attacker’s code is written in the Javascript language, but other scripting languages are also used, e.g., Action- Script and VBScript. Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g., download links). One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding. In some cases, the web server or the web application could not be filtering some encodings of characters, so, for example, the web application might filter out “”, but might not filter %3cscript%3e which simply includes another encoding of tags. How to Test Black Box testing A black-box test will include at least three phases: [1] Detect input vectors. For each web page, the tester must determine all the web application’s user-defined variables and how to input them. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values. Typically in-browser HTML editors or web proxies are used to view these hidden variables. See the example below. Ideally all HTML special characters will be replaced with HTML entities. The key HTML entities to identify are: > (greater than) < (less than) & (ampersand) ‘ (apostrophe or single quote) “ (double quote) However, a full list of entities is defined by the HTML and XML specifications. Wikipedia has a complete reference [1]. Within the context of an HTML action or JavaScript code, a different set of special characters will need to be escaped, encoded, replaced, or filtered out. These characters include: \n (new line) \r (carriage return) \’ (apostrophe or single quote) \” (double quote) \\ (backslash) \uXXXX (unicode values) For a more complete reference, see the Mozilla JavaScript guide. [2] Example 1 For example, consider a site that has a welcome notice “ Welcome %username% “ and a download link. [2] Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the tester will typically use specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web browser that manifests the vulnerability. Testing data can be generated by using a web application fuzzer, an automated predefined list of known attack strings, or manually. Some example of such input data are the following: alert(123) The tester must suspect that every data entry point can result in an XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability. Let’s try to click on the following link and see what happens: “>alert(document.cookie) For a comprehensive list of potential test strings, see the XSS Filter Evasion Cheat Sheet. http: /example.com/index.php?user=alert(123) If no sanitization is applied this will result in the following popup: [3] For each test input attempted in the previous phase, the tester will analyze the result and determine if it represents a vulnerability that has a realistic impact on the web application’s security. This requires examining the resulting web page HTML and searching for the test input. Once found, the tester identifies any special characters that were not properly encoded, replaced, or filtered out. The set of vulnerable unfiltered special characters will depend on the context of that section of 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 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:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50: 47 Web Application Penetration Test
Page 99: 97 Web Application Penetration Test
Page 103 and 104: 101 Web Application Penetration Tes
Page 151 and 152:
149 Web Application Penetration Tes
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?