4. Front End Security Basics: Clickjacking
1. VULNERABILITY EXPLAINED
Clickjacking attacks occur when a page, particularly one with clickable elements, can be placed inside a frame.
An attacking website frames the victim website and redresses it in a manner that it becomes not visible to the victim.
For example, if a website’s profile page has a Delete Account button, an attacker can place an iframe that centers on that button, while placing a fake ad in the topmost page, with a fake X button to close the ad immediately above the Delete Account button. The user then clicks the fake X to skip the ad, but the click passes through it to the Delete Account button in the frame, hijacking the click to perform an attacker’s evil action within the user’s account.
2. EXERCISE BACKGROUND
The vulnerable application pane loads the TraderDASH application. In this application developers introduced a “One-click Trade” functionality that allows a user to quickly buy and sell stocks with a single-click order execution.
Alice is a trader and registered user of the application.
As Alice, go ahead and make some trades.
ACTION
Buy APPL stock by clicking the BUY button (until the amount reaches $6000). Then click NEXT to continue.
3. VULNERABILITY PURSUED
Bob has access to the TraderDASH application, but he does not have access to Alice’s stock portfolio.
Bob knows that if he can just get Alice to sell all her APPL stock, he will then be able to buy the same stock at a lower price.
4. SETTING UP THE ENVIRONMENT
First, Bob registers a domain called stocktips.codebashing.com and configures it to point to his own web server.
On his web server, Bob hosts a malicious web page that contains genuine looking research reports for traders.
Bob then writes a malicious email to Alice, asking her to check out some interesting research he found.
Hi Alice,
Check out this interesting research that my teammate sent to me: https://stocktips.codebashing.com/
Kind Regards,
Bob
Alice would normally ignore unsolicited emails, but because the information looks relevant to her, she decides to open it.
ACTION
As Alice, copy the URL from Bob’s email and paste it into the address bar of the fake browser, then hit Enter.
5. MALICIOUS WEB PAGE LOADED
Alice opens the website using the link provided:
https://stocktips.codebashing.com
This web page seems to load a news report that is relevant to traders like Alice.
6. SOURCE CODE OF THE MALICIOUS PAGE
Before we see the Clickjacking attack in action, let’s first take a look at the source code of Bob’s malicious web page.
Browsing through Bob's malicious HTML, we notice that the web page contains a button tag called "RESEARCH REPORT" which an unsuspecting victim must first click in order to access the research report
Bob has also declared an iframe within his malicious web page that loads https://traderdash.codebashing.com . Note that the iframe has been styled using the CSS opacity: 0 parameter to ensure that the iframe is not visible once Alice has loaded Bob’s malicious web page
7. VULNERABILITY DETECTED
As you can see, the malicious website that Bob created looks harmless.
However, on the last step, we saw that the stock trading page of the TraderDASH application is being loaded in the iframe with opacity: 0.
As Alice was logged in with the application before she clicked Bob’s link, iframe loads her stock trading page.
To understand the impact better, play with the slider at the bottom of the pane to alter the opacity setting of the iframe and opacity of the TraderDASH website correspondingly.
ACTION
Play with the slider at the bottom of the page to adjust the transparency of the web page. Then click NEXT to continue.
8.VULNERABILITY EXPLOITED
Go ahead and click the RESEARCH REPORT button.
Note that as soon as the button is clicked, the Clickjacking attack actually occurs.
The next section will explain it in more detail.
9. RELOAD TRADERDASH WEBSITE
Alice sees that the research report is not loading and decides to go back to the TraderDASH application:
https://traderdash.codebashing.com/
ACTION
As Alice, copy the above URL and paste it into the address bar of the fake browser, then hit Enter.
10. SUCCESSFUL ATTACK RESULTS
Notice that all the purchased APPL shares have now been unintentionally sold.
Alice didn’t realize that when she clicked the RESEARCH REPORT button, she was actually clicking the transparent SELL button within the TraderDASH application.
On the next steps, we’ll learn how these attacks can be prevented.
11. REMEDIATION STRATEGY
There are two ways to combat Clickjacking attacks, both of which are recommended for concurrent implementation: one for modern browsers, one for legacy support.
For modern browsers, the X-Frame-Options response header can be set. This header indicates to the browser which other domains are allowed to frame the web page in the response:
- DENY prevents any sort of framing for the current page
- SAMEORIGIN allows only the current domain to frame pages from its own domain
- ALLOW-FROM allows a single domain URI which may frame the page.
Unfortunately, this means that for multiple domains, the ALLOW-FROM header will require an implementation that would correctly set the header by the request’s referrer header.
Additionally, a Content-Security-Policy header can be set to similarly prevent framing, using frame-ancestors directive that specifies pages that may embed the current page. It has the following values:
- none is the same as DENY
- self is the same as SAMEORIGIN
- Source URI – enables the server administrator to specify scheme, host, and port of allowed parent pages. This directive permits usage of wildcards, e.g. https://*.codebashing.com.
The headers discussed on this page have different compatibility with browsers.
For example, Internet Explorer doesn’t support the Content-Security-Policy frame-ancestors directive.
For further details, please check the following resources:
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors – explains how to set up properly the HTTP Content-Security-Policy frame-ancestors directive
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options – explaines how to set up properly the X-Frame-Options HTTP response header
- https://w3c.github.io/webappsec-csp/#directive-frame-ancestors – the latest version of Content-Security-Policy definition
12. LEGACY SUPPORT
For true legacy support, Javascript framebusting code is required. The original approach was to use the following code as a means of busting the frame:
<script> if (top !== self) { top.location = self.location; } // Attempt to escape frame </script>
In other words, if the topmost window is not the framed window, the framed window attempts to redirect to itself being the top window.
However, this approach is flawed: by using the window.onbeforeunload event, an attacker can create an interception routine to block redirection, leaving the page as is, in what is known as framebusting busting.
To fight this, use the approach described in the fix.
The framed document’s body or html’s display attribute should be set to none. In this case, if framebusting fails, body or html having display set to none would also make any and all elements within it invisible and unclickable, preventing Clickjacking.