Clickjacking, or in more general terms UI (User Interface) redressing, occurs when a malicious actor tricks a victim into clicking on or otherwise interacting with a transparent page sitting atop a legitimate/target website in which he/she is logged. Attackers usually accomplish this by employing HTML frames. For example, the attacker may create invisible
<iframe>s containing the sensitive target page, and overlaying that, build a fake user interface with a false, say, button, which perfectly overlaps the genuine one in the target web page. Finally, the legitimate-looking yet entirely bogus interface is made ethereal by setting the
pointer-events CSS property to
none; thus, the clicks pass straight through and proceed (or are hijacked as inferred in the “clickjack” portmanteau) directly to the invisible target frame.
As both a concept and a known flaw, Clickjacking has been on security practitioners’ minds for almost two decades, and, although interfaces and apps have changed with the times, the overarching “hijacking” method of compromise has largely remained the same.
The impact depends on the target application; the interaction is usually limited to clicking or other simple actions. Still, in any case, the attacker cannot exfiltrate data from the victim. In that sense, the interaction is blind. Regardless of an individual machine’s “worth” as a target, statistics matter, and so if there are numerous successful intrusions, there is more likelihood of a jackpot. In addition, the problem is not going away; in fact, it’s growing. A January 2020 cross-industry survey discovered that Clickjacking accounts for 66 percent of attacks in the education domain.
Suppose the victim is logged in to
myecommerce.com, an e-commerce website that allows, among other things, a user to perform 1-click payments. An attacker could craft a page that lures the victim into clicking on one particular section by, for example, inserting a banner reading “Click here to win this prize”. Unfortunately for our user, the
myecommerce.com button would be lying invisibly beneath. As a result, the victim may end up purchasing an item by clicking the fake, ethereal button.
To prevent the Classic Clickjacking attacks that leverage the web browser alone, in most cases, disallowing applications to load into frames is sufficient. At the very least, checking the origins of apps against an allow list that require frame-loading should be implemented. The canonical way is to use some HTTP headers in every response:
SAMEORIGIN. This is supported by major browsers but has been deprecated in favor of CSP (Content Security Policy).
Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable
Content-Security-Policy: frame-ancestors and
X-Frame-Options response headers.