By Angel Irizarry - October 23, 2014
In another blog post, I discussed a vulnerability called Cross-Site Request Forgery (CSRF) that allows an attacker to force a victim to perform actions on their logged-in sites inadvertently. The defense I recommended was called the Synchronizer Token Pattern, as the defense relies on using randomly-generated tokens to which attackers would not have access. Hackers are both clever and resourceful, however, and if your website is vulnerable to a technique called clickjacking, attackers can force victims of your site to perform unwanted actions even if proper CSRF protections are in place.
This attack is best understood visually. Let’s suppose, only for illustration, that eBay is vulnerable to clickjacking—meaning that an attacker could embed an eBay page in an iframe on their own site. A product listing page looks like the following.
An attacker can construct a website that contains a really enticing button, just begging to be clicked.
Then, they can precisely overlay the eBay iframe so that the “Buy It Now” button sits perfectly on top of the “FREE” button. The following uses a semi-transparent iframe for illustration purposes.
Lastly, they can make the iframe invisible, yet still technically “on top of” the site’s content, so when the user thinks they’ve just clicked on a link, they actually became proud owners of a new car.
In the above example, an attacker can trick an unsuspecting user into buying a Ford. Even if the “Buy It Now” button is inside of a CSRF-protected form, the request goes through, the website has no way to distinguish an intentional click from one contrived by an attacker. This same attack can be used to cause the user harm, such as tricking them into deleting all of their emails by lining up the “Delete All” button under the “FREE” button. An attacker could also trick the user into opening themselves up to further attack by disabling defenses and enabling your webcam. If that’s not scary enough, or you already cover your webcam with black tape, an attacker can construct a precise combination of malicious text fields and buttons and trick a victim into resetting their password for another service.
To prevent this attack, you need to prevent the ability for your site to be embedded as a frame in another site. There are two ways to solve this. In short, there is the established way and the new way. Since we’re in the middle of a transition phase—the new way is still very new and not widely supported—I recommend doing both, to prepare yourself for the inevitable day when the old way is deprecated.
The common way this is done is by adding an HTTP header that serves just this purpose:
X-Frame-Options. As you may know, the
X- prefix indicates that this is a non-standard header; however, this header is understood by all major browsers, including Chrome, Safari, Opera, Firefox, and Internet Explorer 8 and newer. Browsers refuse to load content in an iframe if that content includes this header and the header disallows it. The header has two possible values:
DENY is self-explanatory, and
SAMEORIGIN allows the page to be embedded only within the same domain as the embedding site. There does exist a third option called
ALLOW-FROM uri, but neither Chrome nor Safari plan to support it. Therefore, I do not recommend using
ALLOW-FROM at all.
There’s a new all-encompassing HTTP header that’s on its way to becoming a standard. It’s called
Content-Security-Policy (CSP). The
frame-ancestors, a whitelist of trusted sources that are allowed to include your page in a frame.
If you want to prevent framing of your page entirely, use the CSP header like this:
Content-Security-Policy: frame-ancestors 'none'
To allow framing only within your own site, you can replace
'self'. Alternatively, you can supply a list of allowed, trusted domains. Like all aspects of CSP, it’s very flexible.
Content-Security-Policy: frame-ancestors tinfoilsecurity.com example.com
You can use an automated web security scanner like Tinfoil to crawl your site and ensure that no page is vulnerable to clickjacking. Tinfoil provides the best web application security solution on the market, and it detects clickjacking vulnerabilities on your website along with many other types of web vulnerabilities.
Angel Irizarry is the Software Samurai of Tinfoil Security, and a self-proclaimed software purist. All he needs to do his best work is a plain Linux machine with Git and Emacs installed. He loves everything about front-end development, like making pages interactive and super fast, even if that means digging in and optimizing some SQL. When he's not writing code, which isn't very often, you'll find him on his iPad scouring his RSS feeds for news and rumors of cool new gadgets.
Tinfoil Security provides the simplest security solution. With Tinfoil Security, your site is routinely monitored and checked for vulnerabilities using a scanner that's constantly updated. Using the same techniques as malicious hackers, we systematically test all the access points, instantly notifying you when there's a threat and giving you step-by-step instructions, tailored to your software stack, to eliminate it. You have a lot to manage; let us manage your website's security.