Mozilla advises webmasters to implement X-Frame-Options security header
In light of overall low adoption of HTTP security headers, Mozilla is advising webmasters to at least implement X-Frame-Options on their sites, arguing that this header can prevent several types of attacks.
The X-Frame-Options is an HTTP response header that allows webmasters to define if and how their websites can be loaded into frame elements on other sites. It comes with three options: ALLOW, DENY and SAMEORIGIN, the latter meaning a page can only be framed by other pages with the same origin—same domain, URI scheme and port. There’s a fourth option called ALLOW-FROM, but it’s not supported by all browsers.
If a site X tries to load a page from a site Y into a frame and site Y includes X-Frame-Options DENY in its responses, a modern browser visiting site X will not load the framed page.
This header was primarily created as a security mechanism against clickjacking attacks, which can be used to trick users into performing actions on websites without their knowledge.
A common clickjacking technique is to load a button from a targeted site into an iframe on an attack site and then use legitimate Web development techniques to make the framed content transparent. The framed button can be positioned over a clickable element from the attack site, so that when a site’s visitor attempts to click on the visible element, they actually click on the now invisible button from the targeted website that was positioned on top.
A few years ago this type of attack was common on Facebook, attackers using it to trick users into unknowingly sharing spam messages from their accounts. However, the possibilities for clickjacking-based abuse are varied and depend on the nature of the targeted site.
Despite X-Frame-Options being relatively easy to implement, a scan of the Internet’s top 1 million most trafficked websites by security firm Veracode in November, revealed thatonly around 30,000 sites were using the header and a few hundred of those were actually using it incorrectly.
Clickjacking is not the only type of attack that X-Frame-Options can prevent, Frederik Braun, a security engineer at Mozilla, said Thursday in a blog post.
For example, Internet Explorer allows websites to specify that they want to run in IE7 compatibility mode, meaning they will be rendered with algorithms from Internet Explorer 7 that date back to 2006. IE7 lacks many security mechanisms against content injection attacks that exist in the browser’s newer versions, Braun said.
The problem is that a page loaded in a frame by a site running in IE7 compatibility mode will also be rendered in IE7 compatibility mode. This means attackers can frame a site in a page running in IE7 compatibility mode to defeat the security protections the targeted site would normally offer to users of recent IE versions, according to Braun.
”If the evil website runs in IE7 compatibility mode, then so does yours!” Braun said. If your website would not allow itself to be framed by using X-Frame-Options, your IE users wouldn’t be at risk, he said.
Another technique that involves the window.name attribute could be used to bypass certain restrictions and more easily execute XSS (cross-site scripting) attacks when a site is loaded into a frame, the Mozilla security engineer said.
Braun recently published with another researcher a paper on X-Frame-Options that covers many attacks the header can prevent in detail.
”These and many other attacks are possible if you allow your webpage to be displayed in a frame,” Braun said in the Mozilla blog post. “The fact that many other sites are vulnerable to these sort of attacks is not a good reason to leave your website unprotected. You can easily address many security problems by just adding this simple header to your web application right away.”
The Mozilla developers site includes information on how to configure X-Frame-Options on the Apache and Nginx Web servers and Braun’s blog post contains links to instructions on how to enable the header on Web frameworks like Django and NodeJS.