iFrame clickjacking countermeasures appear in Chrome source code. And it only took *checks calendar* three years

August 20, 2019

iFrame clickjacking countermeasures appear in Chrome source code. And it only took checks calendar three years

Institute For Ethical Hacking Course and Ethical Hacking Training in Pune – India

Extreme Hacking | Sadik Shaikh | Cyber Suraksha Abhiyan

Credits: The Register

Three years ago, Google software engineer Ali Juma proposed that Chrome should be modified to ignore recently moved iframe elements on web pages as a defense against clickjacking.

Clickjacking, a form of online attack also known as user-interface redressing, involves modifying web page elements to hijack click events so they hit an attacker-designated page element. The goal generally is to trigger ad or affiliate payments, to expose information or to install malicious code.

Juma in his proposal didn’t specifically mention clickjacking, though he linked to a YouTube video illustrating just that. The problem, he explained, is that an Inline Frames or iframe – an embedded web page element that can be tied to another Origin (domain) – can be made to move suddenly so that it covers another web page element (like a button or link), thereby intercepting the click event intended for the covered part of the page.

“Web authors might not be sufficiently incentivized to fix this problem themselves, since they benefit from clicks on ads,” Juma wrote. “This means that addressing this problem may require user agents [browsers] to intervene.”

Google, which also benefits from clicks on ads, hasn’t prioritized fixing this problem either, given that the proposal has languished for three years. But the delay appears to have had more to do with job responsibility changes and absent technical capabilities in Chrome.

Certainly some of the search king’s Chrome engineers have made it clear that they recognize clickjacking represents a serious threat and something needs to be done to prevent it.

We IOv2 you, too

At the start of the year, a technological piece of the puzzle fell into place. In January, a web API called IntersectionObserver v2 (IOv2) landed in Chrome developer builds and reached the general public via Chrome 74 in May. Other browsers have yet to adopt it. IOv2 adds the ability to check whether the target page element is visible in a computationally efficient way – it looks for the intersecting geometry of interface elements on a web page – and is intended as a defense against fraud.

“When the iframe processes the click event, it has no way to determine that its content was not faithfully displayed on the screen,” the W3C’s explainer says. “Using IntersectionObserver V2, code running inside the iframe can get a strong guarantee from the implementation that its content was completely visible and unmodified for some minimum length of time before the click.”

In May, Google engineer Stefan Zager revived Juma’s idea and expanded on it, citing the utility of IOv2 to implement the iframe movement monitoring scheme.

“IOv2 is not a complete solution: it will notify an iframe when its contents are hidden or visually altered, but it doesn’t detect when an iframe has moved within the viewport of its embedding page,” Zager’s proposal says. “An iframe can bounce all around the viewport, but as long as it’s continuously visible, IOv2 will not trigger any notifications.”

The intervention he proposes, ignoring input events targeting recently-moved cross-origin iframes, would help make clickjacking more difficult. The capability has been tested in a few Chrome Canary builds but isn’t publicly available at the moment unless you are building Chromium from source code. It doesn’t yet have a target release date. ®