1BO4r2U

Recommendations

Info

197 198 Web Application Penetration Testing Web Application Penetration Testing Cross-Site Flashing Cross-Site Flashing (XSF) is a vulnerability which has a similar impact as XSS. XSF Occurs when from different domains: • One Movie loads another Movie with loadMovie* functions or other hacks and has access to the same sandbox or part of it • XSF could also occurs when an HTML page uses JavaScript to command an Adobe Flash movie, for example, by calling: • GetVariable: access to flash public and static object from JavaScript as a string. • SetVariable: set a static or public flash object to a new string value from JavaScript. • Unexpected Browser to SWF communication could result in stealing data from the SWF application. It could be performed by forcing a flawed SWF to load an external evil flash file. This attack could result in XSS or in the modification of the GUI in order to fool a user to insert credentials on a fake flash form. XSF could be used in the presence of Flash HTML Injection or external SWF files when loadMovie* methods are used. Open redirectors SWFs have the capability to navigate the browser. If the SWF takes the destination in as a FlashVar, then the SWF may be used as an open redirector. An open redirector is any piece of website functionality on a trusted website that an attacker can use to redirect the end-user to a malicious website. These are frequently used within phishing attacks. Similar to cross-site scripting, the attack involves a user clicking on a malicious link. In the Flash case, the malicious URL might look like: http:/trusted.example.org/trusted.swf?getURLValue=http:/ www.evil-spoofing-website.org/phishEndUsers.html In the above example, an end-user might see the URL begins with their favorite trusted website and click on it. The link would load the trusted SWF which takes the getURLValue and provides it to an ActionScript browser navigation call: getURL(_root.getURLValue,”_self”); This would navigate the browser to the malicious URL provided by the attacker. At this point, the phisher has successfully leveraged the trusted the user has in trusted.example.org to trick the user into their malicious website. From their, they could launch a 0-day, conduct spoofing of the original website, or any other type of attack. SWFs may unintentionally be acting as an open-redirector on the website. Developers should avoid taking full URLs as FlashVars. If they only plan to navigate within their own website, then they should use relative URLs or verify that the URL begins with a trusted domain and protocol. Attacks and Flash Player Version Since May 2007, three new versions of Flash player were released by Adobe. Every new version restricts some of the attacks previously described. Attack Player Version v9.0 r47/48 v9.0 r115 v9.0 r124 asfunction Yes No No ExternalInterface Yes Yes Yes Result Expected: Cross-Site Scripting and Cross-Site Flashing are the expected results on a flawed SWF file. Tools • Adobe SWF Investigator: http://labs.adobe.com/technologies/ swfinvestigator/ • SWFScan: http://h30499.www3.hp.com/t5/Following-the-Wh1t3-Rabbit/SWFScan-FREE-Flash-decompiler/bap/5440167 • SWFIntruder: https://www.owasp.org/index.php/Category:SWFIntruder • Decompiler – Flare: http://www.nowrap.de/flare.html • Compiler – MTASC: http://www.mtasc.org/ GetURL Yes Yes Yes • Disassembler – Flasm: http://flasm.sourceforge.net/ Html Injection Yes Yes Partially • Swfmill – Convert Swf to XML and vice versa: http://swfmill.org/ • Debugger Version of Flash Plugin/Player: http://www.adobe.com/ support/flash/downloads.html References OWASP • OWASP Flash Security Project: The OWASP Flash Security project has even more references than what is listed below: http://www. owasp.org/index.php/Category:OWASP_Flash_Security_Project Whitepapers • Testing Flash Applications: A new attack vector for XSS and XSFlashing: http://www.owasp.org/images/8/8c/OWASPAppSec- 2007Milan_TestingFlashApplications.ppt • Finding Vulnerabilities in Flash Applications: http://www.owasp. org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt • Adobe security updates with Flash Player 9,0,124,0 to reduce cross-site attacks: http://www.adobe.com/devnet/flashplayer/ articles/flash_player9_security_update.html • Securing SWF Applications: http://www.adobe.com/devnet/ flashplayer/articles/secure_swf_apps.html • The Flash Player Development Center Security Section: http:// www.adobe.com/devnet/flashplayer/security.html • The Flash Player 10.0 Security Whitepaper: http://www.adobe. com/devnet/flashplayer/articles/flash_player10_security_wp.html Testing for Clickjacking (OTG-CLIENT-009) Summary “Clickjacking” (which is a subset of the “UI redressing”) is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term “Clickjacking” was coined by Jeremiah Grossman and Robert Hansen in 2008. A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a “client side” security issue that affects a variety of browsers and platforms. To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed through the use of CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (like for example social engineering). Like others attacks, an usual prerequisite is that the victim is authenticated against the attacker’s target website. Once the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page. Since the hidden page is an authentic page, the attacker can deceive users into performing actions which they never intended to perform through an “ad hoc” positioning of the elements in the web page. The power of this method is due to the fact that the actions performed by the victim are originated from the authentic target web page (hidden but authentic). Consequently some of the anti-CSRF protections, that are deployed by the developers to protect the web page from CSRF attacks, could be bypassed. How to Test As mentioned above, this type of attack is often designed to allow an attacker site to induce user’s actions on the target site even if anti-CSRF tokens are being used. So it’s important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user. We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a “proof of concept” to exploit the vulnerability. The first step to discover if a website is vulnerable, is to check if the target web page could be loaded into an iframe. To do this you need to create a simple web page that includes a frame containing the target web page. The HTML code to create this testing web page is displayed in the following snippet: Clickjack test page Website is vulnerable to clickjacking! Result Expected: If you can see both the text “Website is vulnerable to clickjacking!” at the top of the page and your target web page successfully loaded into the frame, then your site is vulnerable and has no type of protection against Clickjacking attacks. Now you can directly create a “proof of concept” to demonstrate that an attacker could exploit this vulnerability. Bypass Clickjacking protection: In case in which you only see the target site or the text “Website is vulnerable to clickjacking!” but nothing in the iframe this mean that the target probably has some form of protection against clickjacking. It’s important to note that this isn’t a guarantee that the page is totally immune to clickjacking. Methods to protect a web page from clickjacking can be divided in two macro-categories: • Client side protection: Frame Busting • Server side protection: X-Frame-Options In some circumstances, every single type of defense could be bypassed. Following are presented the main methods of protection from these attacks and techniques to bypass them.
199 200 Web Application Penetration Testing Web Application Penetration Testing Client side protection: Frame Busting The most common client side method, that has been developed to protect a web page from clickjacking, is called Frame Busting and it consists of a script in each page that should not be framed. The aim of this technique is to prevent a site from functioning when it is loaded inside a frame. The structure of frame busting code typically consists of a “conditional statement” and a “counter-action” statement. For this type of protection, there are some work arounds that fall under the name of “Bust frame busting”. Some of this techniques are browser-specific while others work across browsers. Mobile website version Mobile versions of the website are usually smaller and faster than the desktop ones, and they have to be less complex than the main application. Mobile variants have often less protection since there is the wrong assumption that an attacker could not attack an application by the smart phone. This is fundamentally wrong, because an attacker can fake the real origin given by a web browser, such that a non-mobile victim may be able to visit an application made for mobile users. From this assumption follows that in some cases it is not necessary to use techniques to evade frame busting when there are unprotected alternatives, which allow the use of same attack vectors. Double Framing Some frame busting techniques try to break frame by assigning a value to the “parent.location” attribute in the “counter-action” statement. Such actions are, for example: • self.parent.location = document.location • parent.location.href = self.location • parent.location = self.location This method works well until the target page is framed by a single page. However, if the attacker encloses the target web page in one frame which is nested in another one (a double frame), then trying to access to “parent.location” becomes a security violation in all popular browsers, due to the descendant frame navigation policy. This security violation disables the counter-action navigation. Target site frame busting code (target site): if(top.location!=self.locaton) { parent.location = self.location; } Attacker’s top frame (fictitious2.html): Attacker’s fictitious sub-frame (fictitious.html): Disabling javascript Since these type of client side protections relies on JavaScript frame busting code, if the victim has JavaScript disabled or it is possible for an attacker to disable JavaScript code, the web page will not have any protection mechanism against clickjacking. There are three deactivation techniques that can be used with frames: • Restricted frames with Internet Explorer: Starting from Internet Explorer 6, a frame can have the “security” attribute that, if it is set to the value “restricted”, ensures that JavaScript code, ActiveX controls, and re-directs to other sites do not work in the frame. Example: • Sandbox attribute: with HTML5 there is a new attribute called “sandbox”. It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible whit Chrome and Safari. Example: • Design mode: Paul Stone showed a security issue concerning the “designMode” that can be turned on in the framing page (via document.designMode), disabling JavaScript in top and sub-frame. The design mode is currently implemented in Firefox and IE8. onBeforeUnload event The onBeforeUnload event could be used to evade frame busting code. This event is called when the frame busting code wants to destroy the iframe by loading the URL in the whole web page and not only in the iframe. The handler function returns a string that is prompted to the user asking confirm if he wants to leave the page. When this string is displayed to the user is likely to cancel the navigation, defeating traget’s frame busting attempt. The attacker can use this attack by registering an unload event on the top page using the following example code: www.fictitious.site window.onbeforeunload = function() { return “ Do you want to leave fictitious.site?”; } The previous technique requires the user interaction but, the same result, can be achieved without prompting the user. To do this the attacker have to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting (for example every millisecond) a navigation request to a web page that responds with a “HTTP/1.1 204 No Content” header. Since with this response the browser will do nothing, the resulting of this operation is the flushing of the request pipeline, rendering the original frame busting attempt futile. Following an example code: 204 page: Attacker’s page: var prevent_bust = 0; window.onbeforeunload = function() { prevent_bust++; }; setInterval( function() { if (prevent_bust > 0) { prevent_bust -= 2; window.top.location = “http:/attacker.site/204.php”; } }, 1); XSS Filter Starting from Google Chrome 4.0 and from IE8 there were introduced XSS filters to protect users from reflected XSS attacks. Nava and Lindsay have observed that these kind of filters can be used to deactivate frame busting code by faking it as malicious code. • IE8 XSS filter: this filter has visibility into all requests and responses parameters flowing through the web browser and it compares them to a set of regular expressions in order to look for reflected XSS attempts. When the filter identifies a possible XSS attacks; it disable all inline scripts within the page, including frame busting scripts (the same thing could be done with external scripts). For this reason an attacker could induces a false positive by inserting the beginning of the frame busting script into a request parameters. Example: Target web page frame busting code: if ( top != self ) { top.location=self.location; } Attacker code: • Chrome 4.0 XSSAuditor filter: It has a little different behaviour compared to IE8 XSS filter, in fact with this filter an attacker could deactivate a “script” by passing its code in a request parameter. This enables the framing page to specifically target a single snippet containing the frame busting code, leaving all the other codes intact. Example: Target web page frame busting code: if ( top != self ) { top.location=self.location; } Attacker code: Redefining location For several browser the “document.location” variable is an immutable attribute. However, for some version of Internet Explorer and Safari, it is possible to redefine this attribute. This fact can be exploited to evade frame busting code. • Redefining location in IE7 and IE8: it is possible to redefine “location” as it is illustrated in the following example. By defining “location” as a variable, any code that tries to read or to navigate by assigning “top.location” will fail due to a security violation and so the frame busting code is suspended. Example: var location = “xyz”; • Redefining location in Safari 4.0.4: To bust frame busting code with “top.location” it is possible to bind “location” to a function via defineSetter (through window), so that an attempt to read or navigate to the “top.location” will fail. Example: window.defineSetter(“location” , function(){});
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: 95 96 Web Application Penetration T
Page 51 and 52: 99 100 Web Application Penetration
Page 99: 195 196 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?