4.0

More documents

Recommendations

Info

66 Web Application Penetration Testing ery client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing have the same concept based on the analysis of messages or error codes received from web application. Result Expected: The application should answer in the same manner for every failed attempt of authentication. For Example: Credentials submitted are not valid Tools • WebScarab: OWASP_WebScarab_Project • CURL: http://curl.haxx.se/ • PERL: http://www.perl.org • Sun Java Access & Identity Manager users enumeration tool: http://www.aboutsecurity.net References • Marco Mella, Sun Java Access & Identity Manager Users enumeration: http://www.aboutsecurity.net • Username Enumeration Vulnerabilities: http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities Remediation Ensure the application returns consistent generic error messages in response to invalid account name, password or other user credentials entered during the log in process. Ensure default system accounts and test accounts are deleted prior to releasing the system into production (or exposing it to an untrusted network). Testing for Weak or unenforced username policy (OTG-IDENT-005) Summary User account names are often highly structured (e.g. Joe Bloggs account name is jbloggs and Fred Nurks account name is fnurks) and valid account names can easily be guessed. Test objectives Determine whether a consistent account name structure renders the application vulnerable to account enumeration. Determine whether the application’s error messages permit account enumeration. How to test • Determine the structure of account names. • Evaluate the application’s response to valid and invalid account names. • Use different responses to valid and invalid account names to enumerate valid account names. • Use account name dictionaries to enumerate valid account names. Remediation Ensure the application returns consistent generic error messages in response to invalid account name, password or other user credentials entered during the log in process. Authentication Testing Authentication (Greek: αυθεντικός = real or genuine, from ‘authentes’ = author ) is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. Authenticating an object may mean confirming its provenance, whereas authenticating a person often consists of verifying her identity. Authentication depends upon one or more authentication factors. In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication. A common example of such a process is the log on process. Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism. Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001) Summary Testing for credentials transport means verifying that the user’s authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily mean that it’s completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the application is using, but this particular topic will not be addressed in this section. For a more detailed discussion on testing the safety of TLS/SSL channels refer to the chapter Testing for Weak SSL/TLS. Here, the tester will just try to understand if the data that users put in to web forms in order to log in to a web site, are transmitted using secure protocols that protect them from an attacker. Nowadays, the most common example of this issue is the log in page of a web application. The tester should verify that user’s credentials are transmitted via an encrypted channel. In order to log in to a web site, the user usually has to fill a simple form that transmits the inserted data to the web application with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, which transmits the data in a non-secure, clear text form, or using the HTTPS protocol, which encrypts the data during the transmission. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensitive information by simply sniffing the network with a sniffer tool. How to Test Black Box testing In the following examples we will use WebScarab in order to cap-
67 Web Application Penetration Testing ture packet headers and to inspect them. You can use any web proxy that you prefer. Example 1: Sending data with POST method through HTTP Suppose that the login page presents a form with fields User, Pass, and the Submit button to authenticate and give access to the application. If we look at the headers of our request with WebScarab, we can get something like this: POST http:/www.example.com/AuthenticationServlet HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http:/www.example.com/index.jsp Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S! Content-Type: application/x-www-form-urlencoded Content-length: 64 delegated_service=218&User=test&Pass=test&Submit=- SUBMIT From this example the tester can understand that the POST request sends the data to the page www.example.com/AuthenticationServlet using HTTP. Sothe data is transmitted without encryption and a malicious user could intercept the username and password by simply sniffing the network with a tool like Wireshark. Example 2: Sending data with POST method through HTTPS Suppose that our web application uses the HTTPS protocol to encrypt the data we are sending (or at least for transmitting sensitive data like credentials). In this case, when logging on to the web application the header of our POST request would be similar to the following: POST https:/www.example.com:443/cgi-bin/login.cgi HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https:/www.example.com/cgi-bin/login.cgi Cookie: language=English; Content-Type: application/x-www-form-urlencoded Content-length: 50 Command=Login&User=test&Pass=test We can see that the request is addressed to www.example. com:443/cgi-bin/login.cgi using the HTTPS protocol. This ensures that our credentials are sent using an encrypted channel and that the credentials are not readable by a malicious user using a sniffer. Example 3: sending data with POST method via HTTPS on a page reachable via HTTP Now, imagine having a web page reachable via HTTP and that only data sent from the authentication form are transmitted via HTTPS. This situation occurs, for example, when we are on a portal of a big company that offers various information and services that are publicly available, without identification, but the site also has a private section accessible from the home page when users log in. So when we try to log in, the header of our request will look like the following example: POST https:/www.example.com:443/login.do HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404 Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http:/www.example.com/homepage.do Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH- 0QNSJ3VQB6pLhjkW6F Content-Type: application/x-www-form-urlencoded Content-length: 45 User=test&Pass=test&portal=ExamplePortal We can see that our request is addressed to www.example. com:443/login.do using HTTPS. But if we have a look at the Referer-header (the page from which we came), it is www.example. com/homepage.do and is accessible via simple HTTP. Although we are sending data via HTTPS, this deployment can allow SSL- Strip attacks (a type of Man-in-the-middle attack) Example 4: Sending data with GET method through HTTPS In this last example, suppose that the application transfers data using the GET method. This method should never be used in a form that transmits sensitive data such as username and password, because the data is displayed in clear text in the URL and this causes a whole set of security issues. For example, the URL that is requested is easily available from the server logs or from your browser history, which makes your sensitive data retrievable for unauthorized persons. So this example is purely demonstrative, but, in reality, it is strongly suggested to use the POST method instead. GET https: /www.example.com/success.html?user=test&- pass=test HTTP/1.1 Host: www.example.com
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 67: 65 Web Application Penetration Test
Page 103 and 104: 101 Web Application Penetration Tes
Page 119 and 120:
117 Web Application Penetration Tes
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?