4.0

More documents

Recommendations

Info

92Web Application Penetration Testingwhich public documents a registered user downloads) it is essentialthat a different Session ID is used. The Session ID shouldtherefore be monitored as the client switches from the secure tonon-secure elements to ensure a different one is used.Result Expected:Every time the authentication is successful, the user should expectto receive:• A different session token• A token sent via encrypted channel every time they make anHTTP RequestTesting for Proxies & Caching vulnerabilities:Proxies must also be considered when reviewing application security.In many cases, clients will access the application throughcorporate, ISP, or other proxies or protocol aware gateways (e.g.,Firewalls). The HTTP protocol provides directives to control thebehavior of downstream proxies, and the correct implementationof these directives should also be assessed.In general, the Session ID should never be sent over unencryptedtransport and should never be cached. The application should beexamined to ensure that encrypted communications are both thedefault and enforced for any transfer of Session IDs. Furthermore,whenever the Session ID is passed, directives should be in place toprevent its caching by intermediate and even local caches.The application should also be configured to secure data in cachesover both HTTP/1.0 and HTTP/1.1 – RFC 2616 discusses the appropriatecontrols with reference to HTTP. HTTP/1.1 provides a numberof cache control mechanisms. Cache-Control: no-cache indicatesthat a proxy must not re-use any data. Whilst Cache-Control: Privateappears to be a suitable directive, this still allows a non-sharedproxy to cache data. In the case of web-cafes or other shared systems,this presents a clear risk. Even with single-user workstationsthe cached Session ID may be exposed through a compromise ofthe file-system or where network stores are used. HTTP/1.0 cachesdo not recognise the Cache-Control: no-cache directive.Result Expected:The “Expires: 0” and Cache-Control: max-age=0 directives shouldbe used to further ensure caches do not expose the data. Eachrequest/response passing Session ID data should be examined toensure appropriate cache directives are in use.Testing for GET & POST vulnerabilities:In general, GET requests should not be used, as the Session IDmay be exposed in Proxy or Firewall logs. They are also far moreeasily manipulated than other types of transport, although itshould be noted that almost any mechanism can be manipulatedby the client with the right tools. Furthermore, Cross-site Scripting(XSS) attacks are most easily exploited by sending a speciallyconstructed link to the victim. This is far less likely if data is sentfrom the client as POSTs.Result Expected:All server side code receiving data from POST requests should betested to ensure it does not accept the data if sent as a GET. Forexample, consider the following POST request generated by a login page.POST http:/owaspapp.com/login.asp HTTP/1.1Host: owaspapp.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.0.2) Gecko/20030208 Netscape/7.02 Paros/3.0.2bAccept: */*Accept-Language: en-us, enAccept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66Keep-Alive: 300Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJGCache-Control: max-age=0Content-Type: application/x-www-form-urlencodedContent-Length: 34Login=Username&password=Password&SessionID=12345678If login.asp is badly implemented, it may be possible to log in usingthe following URL: http: /owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678Potentially insecure server-side scripts may be identified bychecking each POST in this way.Testing for Transport vulnerabilities:All interaction between the Client and Application should be testedat 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 IDsunencrypted? e.g., by changing HTTP to HTTPS?• What cache-control directives are applied to requests/responsespassing Session IDs?• Are these directives always present? If not, where are theexceptions?• Are GET requests incorporating the Session ID used?• If POST is used, can it be interchanged with GET?ReferencesWhitepapers• 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.txtTesting for CSRF (OTG-SESS-005)SummaryCSRF is an attack which forces an end user to execute unwantedactions on a web application in which he/she is currently authenticated.With a little help of social engineering (like sending a linkvia email or chat), an attacker may force the users of a web applicationto execute actions of the attacker’s choosing. A successfulCSRF exploit can compromise end user data and operation, whenit targets a normal user. If the targeted end user is the administratoraccount, a CSRF attack can compromise the entire webapplication.CSRF relies on the following:[1] Web browser behavior regarding the handling of session-re-
93Web Application Penetration Testinglated 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 informationwhich is known by the browser;[4] Existence of HTML tags whose presence cause immediate accessto 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 usedto identify a user session. Suppose site is a site hosting a webapplication, and the user victim has just authenticated himself tosite. In response, site sends victim a cookie which identifies requestssent by victim as belonging to victim’s authenticated session.Basically, once the browser receives the cookie set by site, itwill automatically send it along with any further requests directedto site.Point 2) If the application does not make use of session-relatedinformation in URLs, then it means that the application URLs,their parameters, and legitimate values may be identified (eitherby code analysis or by accessing the application and taking note offorms and URLs embedded in the HTML/JavaScript).Point 3) ”Known by the browser” refers to information such ascookies, or http-based authentication information (such as BasicAuthentication; and not form-based authentication), which arestored by the browser and subsequently resent at each requestdirected towards an application area requesting that authentication.The vulnerabilities discussed next apply to applications whichrely 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 victimhas already authenticated himself, submitting another requestcauses 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. Inparticular, the third may be quite dangerous. There are a numberof techniques (and of vulnerabilities) which can disguise the realproperties 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 authenticatedby the web application on site, the browser will issue a GETrequest to the web application, accompanied by authentication information(the session id cookie). This results in a valid operationperformed on the web application and probably not what the userexpects to happen. Think of a malicious link causing a fund transferon a web banking application to appreciate the implications.By using a tag such as img, as specified in point 4 above, it is noteven necessary that the user follows a particular link. Suppose theattacker sends the user an email inducing him to visit an URL referringto a page containing the following (oversimplified) HTML:......What the browser will do when it displays this page is that it willtry to display the specified zero-width (i.e., invisible) image as well.This results in a request being automatically sent to the web applicationhosted on site. It is not important that the image URLdoes not refer to a proper image, its presence will trigger the requestspecified in the src field anyway. This happens provided thatimage download is not disabled in the browsers, which is a typicalconfiguration since disabling images would cripple most web applicationsbeyond usability.The problem here is a consequence of the following facts:• there are HTML tags whose appearance in a page result inautomatic http request execution (img being one of those);• the browser has no way to tell that the resource referenced byimg is not actually an image and is in fact not legitimate;• image loading happens regardless of the location of the allegedimage, i.e., the form and the image itself need not be locatedin the same host, not even in the same domain. While this isa very handy feature, it makes difficult to compartmentalizeapplications.It is the fact that HTML content unrelated to the web applicationmay refer components in the application, and the fact thatthe browser automatically composes a valid request towards theapplication, that allows such kind of attacks. As no standards aredefined right now, there is no way to prohibit this behavior unlessit is made impossible for the attacker to specify valid applicationURLs. This means that valid URLs must contain information relatedto the user session, which is supposedly not known to theattacker and therefore make the identification of such URLs impossible.The problem might be even worse, since in integrated mail/
Page 1 and 2:
1Testing Guide4.0Project Leaders: M
Page 3 and 4:
Testing Guide Foreword - Table of c
Page 5 and 6:
3Testing Guide Foreword - Table of
Page 7 and 8:
5Testing Guide Foreword - By Eoin K
Page 9 and 10:
7Testing Guide Frontispiece1Testing
Page 11 and 12:
9Testing Guide Introduction2The OWA
Page 13 and 14:
11Testing Guide Introductionvide en
Page 15 and 16:
13Testing Guide IntroductionTesting
Page 17 and 18:
15Testing Guide Introductionlaid on
Page 19 and 20:
17Testing Guide Introductionvalidat
Page 21 and 22:
19Testing Guide IntroductionUSERthe
Page 23 and 24:
21Testing Guide Introductionment wh
Page 25 and 26:
23Testing Guide Introductionoffendi
Page 27 and 28:
25The OWASP Testing Frameworksectio
Page 29 and 30:
27Web Application Penetration Testi
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: 41Web Application Penetration Testi
Page 93: 91Web Application Penetration Testi
Page 103 and 104: 101Web Application Penetration Test
Page 145 and 146:
143Web Application Penetration Test
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:
209same code can be applied to sess
Page 213 and 214:
211ReportingTest IDLowest versionIn
Page 215 and 216:
213ReportingTest IDBusiness Logic T
Page 217 and 218:
215Appendixkajfghlhfkcocafkcjlajldi
Page 219 and 220:
217AppendixTesting - http:/www.nist
Page 221 and 222:
219Cross Site Scripting (XSS)For de
Page 223 and 224:
221LDAP InjectionFor details on LDA
show all

4.0

Create successful ePaper yourself

Delete template?

Save as template?