4.0

More documents

Recommendations

Info

206 Web Application Penetration Testing Input Sanitization As with any data originating from untrusted sources, the data should be properly sanitised and encoded. Look out for Top 10 2013-A1-Injection and Top 10 2013-A3-Cross-Site Scripting (XSS) type issues. How to Test Black Box testing 1. Identify that the application is using WebSockets. • Inspect the client-side source code for the ws:// or wss:// URI scheme. • Use Google Chrome’s Developer Tools to view the Network WebSocket communication. • Use OWASP Zed Attack Proxy (ZAP)’s WebSocket tab. Example 2 Using a WebSocket client (one can be found in the Tools section below) attempt to connect to the remote WebSocket server. If the connection is allowed the WebSocket server may not be checking the WebSocket handshake’s origin header. Attempt to replay requests previously intercepted to verify that cross-domain WebSocket communication is possible. 2. Origin. • Using a WebSocket client (one can be found in the Tools section below) attempt to connect to the remote WebSocket server. If a connection is established the server may not be checking the origin header of the WebSocket handshake. 3. Confidentiality and Integrity. • Check that the WebSocket connection is using SSL to transport sensitive information (wss://). • Check the SSL Implementation for security issues (Valid Certificate, BEAST, CRIME, RC4, etc). Refer to the Testing for Weak SSL/ TLS Ciphers, Insufficient Transport Layer Protection (OTG- CRYPST-001) section of this guide. 4. Authentication. • WebSockets do not handle authentication, normal black box authentication tests should be carried out. Refer to the Authentication Testing sections of this guide. 5. Authorization. • WebSockets do not handle authorization, normal black-box authorization tests should be carried out. Refer to the Authorization Testing sections of this guide. 6. Input Sanitization. • Use OWASP Zed Attack Proxy (ZAP)’s WebSocket tab to replay and fuzz WebSocket request and responses. Refer to the Testing for Data Validation sections of this guide. Example 1 Once we have identified that the application is using WebSockets (as described above) we can use the OWASP Zed Attack Proxy (ZAP) to intercept the WebSocket request and responses. ZAP can then be used to replay and fuzz the WebSocket request/responses. Gray Box testing Gray box testing is similar to black box testing. In gray box testing the pen-tester has partial knowledge of the application. The only difference here is that you may have API documentation for the application being tested which includes the expected WebSocket request and responses. Tools • OWASP Zed Attack Proxy (ZAP) - https://www.owasp.org/index php/OWASP_Zed_Attack_Proxy_Project ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually. • WebSocket Client - https://github.com/RandomStorm/scripts blob/master/WebSockets.html A WebSocket client that can be used to interact with a WebSocket server. • Google Chrome Simple WebSocket Client - https://chrome google.com/webstore/detail/simple-websocket-client/ pfdhoblngboilpfeibdedpjgfnlcodoo?hl=en Construct custom Web Socket requests and handle responses to directly test your Web Socket services. References Whitepapers • HTML5 Rocks - Introducing WebSockets: Bringing Sockets to the Web: http://www.html5rocks.com/en/tutorials/websockets/ basics/ • W3C - The WebSocket API: http://dev.w3.org/html5/websockets/ • IETF - The WebSocket Protocol: https://tools.ietf.org/html rfc6455
207 Web Application Penetration Testing • Christian Schneider - Cross-Site WebSocket Hijacking (CSWSH): http://www.christian-schneider.net/ CrossSiteWebSocketHijacking.html • Jussi-Pekka Erkkilä - WebSocket Security Analysis: http://juerkkil iki.fi/files/writings/websocket2012.pdf • Robert Koch- On WebSockets in Penetration Testing: http://www ub.tuwien.ac.at/dipl/2013/AC07815487.pdf • DigiNinja - OWASP ZAP and Web Sockets: http://www.digininja org/blog/zap_web_sockets.php Test Web Messaging (OTG-CLIENT-011) Summary Web Messaging (also known as Cross Document Messaging) allows applications running on different domains to communicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy and enforced by the browser, however developers used multiple hacks in order to accomplish these tasks, most of them were mainly insecure. This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced within he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows. The Messaging API introduced the postMessage() method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. There are some security concerns when using ‘*’ as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes: • data: The content of the incoming message • origin: The origin of the sender document • source: source window An example: Send message: iframe1.contentWindow.postMessage(“Hello world”,”http: / www.example.com”); Receive message: window.addEventListener(“message”, handler, true); function handler(event) { if(event.origin === ‘chat.example.com’) { /* process message (event.data) */ } else { /* ignore messages from untrusted domains */ } } Origin Security Concept The origin is made up of a scheme, host name and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url. For instance, https:// example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to web servers running in the same domain but different port. From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish this is using a whitelist. Also within the sending domain, we also want to make sure they are explicitly stating the receiving domain and not ‘*’ as the second argument of post- Message() as this practice could introduce security concerns too, and could lead to, in the case of a redirection or if the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers. In the case the website failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risk so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message event listeners, and get the callback function from the addEventListener method to further analysis as domains must be always be verified prior data manipulation. event.data Input Validation Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via eval() or inserted into the DOM via the innerHTML property as that would create a DOM-based XSS vulnerability. How to Test Black Box testing Black box testing for vulnerabilities on Web Messaging 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 Manual testing needs to be conducted and the JavaScript code analyzed looking for how Web Messaging is implemented. In particular we should be interested in how the website is restricting messages from untrusted domain and how the data is handled even for trusted domains. Below are some examples: Vulnerable code example: In this example, access is needed for every subdomain (www, chat, forums, ...) within the owasp.org domain. The code is trying to accept any domain ending on .owasp.org:
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:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158: 155 Web Application Penetration Tes
Page 207: 205 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?