1BO4r2U

Recommendations

Info

201 202 Web Application Penetration Testing Web Application Penetration Testing Server side protection: X-Frame-Options An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new “X-FRAME-OPTIONS” header is sent from the server on HTTP responses and is used to mark web pages that shouldn’t be framed. This header can take the values DENY, SAMEORIGIN, ALLOW-FROM origin, or non-standard ALLOWALL. Recommended value is DENY. The “X-FRAME-OPTIONS” is a very good solution, and was adopted by major browser, but also for this technique there are some limitations that could lead in any case to exploit the clickjacking vulnerability. Browser compatibility Since the “X-FRAME-OPTIONS” was introduced in 2009, this header is not compatible with old browser. So every user that doesn’t have an updated browser could be victim of clickjacking attack. Browser Internet Explorer Firefox (Gecko) Opera Safari Chrome Lowest version 8.0 3.6.9 (1.9.2.9) 10.50 4.0 4.1.249.1042 Proxies Web proxies are known for adding and stripping headers. In the case in which a web proxy strips the “X-FRAME-OPTIONS” header then the site loses its framing protection. Mobile website version Also in this case, since the “X-FRAME-OPTIONS” has to be implemented in every page of the website, the developers may have not protected the mobile version of the website. Create a “proof of concept” Once we have discovered that the site we are testing is vulnerable to clickjacking attack, we can proceed with the development of a “proof of concept” to demonstrate the vulnerability. It is important to note that, as mentioned previously, these attacks can be used in conjunction with other forms of attacks (for example CSRF attacks) and could lead to overcome anti-CSRF tokens. In this regard we can imagine that, for example, the target site allows to authenticated and authorized users to make a transfer of money to another account. Suppose that to execute the transfer the developers have planned three steps. In the first step the user fill a form with the destination account and the amount. In the second step, whenever the user submits the form, is presented a summary page asking the user confirmation (like the one presented in the following picture). Following a snippet of the code for the step 2: /generate random anti CSRF token $csrfToken = md5(uniqid(rand(), TRUE)); /set the token as in the session data $_SESSION[‘antiCsrf’] = $csrfToken; /Transfer form with the hidden field $form = ‘ BANK XYZ - Confirm Transfer Do You want to confirm a transfer of ’. $_REQUEST[‘amount’] .’ € to account: ’. $_RE- QUEST[‘account’] .’ ? ’; In the last step are planned security controls and then, if is all ok, the transfer is done. Following is presented a snippet of the code of the last step (Note: in this example, for simplicity, there is no input sanitization, but it has no relevance to block this type of attack): if( (!empty($_SESSION[‘antiCsrf’])) && (!empty($_POST[‘antiCsrf’])) ) { /here we can suppose input sanitization code… /check the anti-CSRF token if( ($_SESSION[‘antiCsrf’] == $_POST[‘antiCsrf’]) ) { echo ‘ ‘. $_POST[‘amount’] .’ € successfully transfered to account: ‘. $_POST[‘account’] .’ ’; } } else { } echo ‘Transfer KO’; As you can see the code is protected from CSRF attack both with a random token generated in the second step and accepting only variable passed via POST method. In this situation an attacker could forge a CSRF + Clickjacking attack to evade anti-CSRF protection and force a victim to do a money transfer without her consent. The target page for the attack is the second step of the money transfer procedure. Since the developers put the security controls only in the last step, thinking that this is secure enough, the attacker could pass the account and amount parameters via GET method. (Note: there is an advanced clickjacking attack that permits to force users to fill a form, so also in the case in which is required to fill a form, the attack is feasible). The attacker’s page may look a simple and harmless web page like the one presented below: But playing with the CSS opacity value we can see what is hidden under a seemingly innocuous web page. The clickjacking code the create this page is presented below: Trusted web page class=”button” value=”Click and go!”> border: 1px solid opacity:0.0 www.owasp.com
203 204 Web Application Penetration Testing Web Application Penetration Testing Tools • Context Information Security: “Clickjacking Tool” - http://www. contextis.com/research/tools/clickjacking-tool/ References OWASP Resources • Clickjacking Whitepapers • Marcus Niemietz: “UI Redressing: Attacks and Countermeasures Revisited” - http://ui-redressing.mniemietz.de/uiRedressing.pdf • “Clickjacking” - https://en.wikipedia.org/wiki/Clickjacking • Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: “Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites” - http://seclab.stanford.edu/websec/framebusting/ framebust.pdf • Paul Stone: “Next generation clickjacking” - https://media.blackhat. com/bh-eu-10/presentations/Stone/BlackHat-EU-2010-Stone- Next-Generation-Clickjacking-slides.pdf Testing WebSockets (OTG-CLIENT-010) Summary Traditionally the HTTP protocol only allows one request/response per TCP connection. Asynchronous JavaScript and XML (AJAX) allows clients to send and receive data asynchronously (in the background without a page refresh) to the server, however, AJAX requires the client to initiate the requests and wait for the server responses (half-duplex). HTML5 WebSockets allow the client/server to create a ‘full-duplex’ (two-way) communication channels, allowing the client and server to truly communicate asynchronously. WebSockets conduct their initial ‘upgrade’ handshake over HTTP and from then on all communication is carried out over TCP channels by use of frames. Origin It is the server’s responsibility to verify the Origin header in the initial HTTP WebSocket handshake. If the server does not validate the origin header in the initial WebSocket handshake, the WebSocket server may accept connections from any origin. This could allow attackers to communicate with the WebSocket server cross-domain allowing for Top 10 2013-A8-Cross-Site Request Forgery (CSRF) type issues. Confidentiality and Integrity WebSockets can be used over unencrypted TCP or over encrypted TLS. To use unencrypted WebSockets the ws:// URI scheme is used (default port 80), to use encrypted (TLS) WebSockets the wss:// URI scheme is used (default port 443). Look out for Top 10 2013-A6-Sensitive Data Exposure type issues. Authentication WebSockets do not handle authentication, instead normal application authentication mechanisms apply, such as cookies, HTTP Authentication or TLS authentication. Look out for Top 10 2013-A2-Broken Authentication and Session Management type issues. Authorization WebSockets do not handle authorization, normal application authorization mechanisms apply. Look out for Top 10 2013-A4-Insecure Direct Object References and Top 10 2013-A7-Missing Function Level Access Control type issues. 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 Web- Socket communication. • Use OWASP Zed Attack Proxy (ZAP)’s WebSocket tab. 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. 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. 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 • 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 */ } }
Page 1 and 2:
1 2 THE ICONS BELOW REPRESENT WHAT
Page 3 and 4:
3 4 Testing Guide Frontispiece Test
Page 5 and 6:
7 8 Testing Guide Introduction Test
Page 7 and 8:
11 12 Testing Guide Introduction Te
Page 9 and 10:
15 16 Testing Guide Introduction Te
Page 11 and 12:
19 20 Testing Guide Introduction of
Page 13 and 14:
23 24 Web Application Penetration T
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
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: 99 100 Web Application Penetration
Page 101: 199 200 Web Application Penetration
Page 107 and 108: 211 212 Reporting Appendix Test ID
Page 109 and 110: 215 216 Appendix Appendix Testing -
Page 111: 219 220 LDAP Injection For details
show all

1BO4r2U

Create successful ePaper yourself

Delete template?

Save as template?