Ready for another cool web application penetration test trick? In this installment we'll cover clickjacking, also known as "UI redressing". Clickjacking is an instance of the classic "confused deputy" problem, and occurs when attackers leverage framesets and stylesheets in order to create opaque bottom and transparent top layers within the victim's browser. The target web application is loaded within the transparent top layer, while a dummy web application is loaded within the bottom opaque layer. By aligning elements between the transparent top and opaque bottom layers, attackers entice the victim to click on something within the opaque bottom layer, but the transparent top layer hijacks the click and performs some unintended action.
For example, the dummy web application loaded within the opaque bottom layer could inform the victim that they have won $1,000 and they simply need to click the "Claim Prize" button in order to cash in. Meanwhile, the victim's email application is loaded within the top transparent layer, and the "Delete Message" button is aligned with the "Claim Your Prize" button. When the victim attempts to click the "Claim Prize" button within the opaque bottom layer, the click is hijacked by the transparent top layer and the victim's email message is deleted. Refer to https://www.owasp.org/index.php/Clickjacking for more information regarding clickjacking.
The best solution to clickjacking is the X-FRAME-OPTIONS server response header. Setting the X-FRAME-OPTIONS header to DENY or SAMEORIGIN prevents the target web application from being loaded within an <IFRAME> or <FRAMESET>, effectively preventing clickjacking attacks. For example, a request to http://www.google.com/ returns the following response header:
X-FRAME-OPTIONS: SAMEORIGIN
The X-FRAME-OPTIONS response header is supported by the latest release of all major browsers, including Mozilla Firefox, Google Chrome, Microsoft Internet Explorer, and Apple Safari. However, there is another solution to clickjacking. Framebreaker code, also known as "framebuster" or "framekiller" code, is a snippet of JavaScript code that prevents the page from being loaded within an <IFRAME> or <FRAMESET>. Consider simple framebreaker code:
if(top.location != self.location) { top.location = self.location; }
If the page is not the top element (i.e., the page is being loaded into an <IFRAME> or <FRAMESET>), the page reloads itself into the top element (i.e., the page breaks out of the <IFRAME> or <FRAMESET>). Note that there are limitations to framebreaker code. Refer to https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet for optimal framebreaker code.
Because there are multiple ways to prevent clickjacking, each solution must be tested individually. In addition, framebreaker code is often buried within recursively included JavaScript files, making testing slow and tedious. So what's the trick? Simply attempt to load the target page within an <IFRAME> and see if the page loads! Why bother inspecting response headers and digging through a maze of JavaScript files? Consider the following Clickjacking Test page loaded with http://www.google.com/:
<HTML>
<BODY>
<H1>Clickjacking Test</H1>
<IFRAME SRC="http://www.google.com/" HEIGHT="600" WIDTH="800"></IFRAME>
</BODY>
</HTML>
If http://www.google.com/ is displayed within the <IFRAME>, the web application is vulnerable. We know that http://www.google.com/ returns the X-FRAME-OPTIONS response header set to SAMEORIGIN, so it is indeed not vulnerable:
Conversely, consider the Clickjacking Test page loaded with http://www.microsoft.com/:
<HTML>
<BODY>
<H1>Clickjacking Test</H1>
<IFRAME SRC="http://www.microsoft.com/" HEIGHT="600" WIDTH="800"></IFRAME>
</BODY>
</HTML>
The http://www.microsoft.com/ application is indeed vulnerable to clickjacking:
Piece of cake! That's all for this installment of the "Web Application Penetration Test Tricks" blog series. Next time we'll consider a subtle and often overlooked vulnerability related to web application authentication. Cheers!