No clickjacking protection configured
ID |
javascript.clickjacking |
Severity |
high |
Resource |
UI |
Language |
JavaScript |
Tags |
CAPEC:103, CWE:1021, NIST.SP.800-53, OWASP:2021:A4, PCI-DSS:6.5.1 |
Description
The OWASP Clickjacking page describes a type of attack known as clickjacking:
Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page.
Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.
Rationale
Clickjacking tries to trick users into clicking on actionable content on a hidden website by clicking on some other content in a decoy website. Consider the following example: A web user accesses a decoy website (perhaps by opening a link provided in an email) and clicks on a button to "win a prize". Unknowingly, they have been deceived by an attacker into pressing an alternative hidden button and this results in the payment of an account on another site. The technique depends upon the incorporation of an invisible, actionable web page (or multiple pages) containing a button or hidden link, say, within an iframe. The iframe is overlaid on top of the user’s anticipated decoy web page content.
As an example of a recent real-world Clickjacking vulnerability, see CVE-2024-10454.
This detector reports a clickjacking vulnerability for a web application that does not use any of the headers or directives that prevent clickjacking, as shown in the remediation section.
This is an example for an web application using the express
framework:
// No specific prevention headers
// (Content-Security-Policy:frame-ancestors, X-Frame-Options)
var express = require('express')
var app = express() // FLAW
app.get('/', function (req, res) {
// ...
})
Remediation
There are three main ways to prevent clickjacking:
-
frame-ancestors: Sending the proper Content Security Policy (CSP)
frame-ancestors
directive response headers that instruct the browser to not allow framing from other domains. The olderX-Frame-Options
HTTP headers are used for graceful degradation and older browser compatibility. -
Preventing session cookie access from frames with SameSite=Strict: As an additional mitigation strategy, configure the same-origin policy for authentication cookies with
SameSite=Strict
(or Lax), unless they explicitly needNone
(which is rare). -
frame-busting: Employing JavaScript defensive code in the UI to ensure that the current frame is the most top level window. Although frame-busting was commonly used in the past, it is no longer recommended as the only remediation as attackers often can bypass it.
See Clickjacking Defense in OWASP Cheat Sheet Series for further information.
The following example fixes the clickjacking vulnerability by setting the appropriate headers:
// Add both headers to protect against clickjacking
app.use(function(req, res, next) {
// FIXED
res.set('X-Frame-Options', 'SAMEORIGIN');
res.set('Content-Security-Policy', "frame-ancestors 'none'");
next();
});
// Alternatively, use helmet (or koa-helmet if under Koa)
var helmet = require('helmet');
app.use( helmet.frameguard() ); // FIXED
// or simply app.use( helmet() ) for all default headers, including X-Frame-Options
References
-
CWE-1021 : Improper Restriction of Rendered UI Layers or Frames.
-
OWASP - Top 10 2021 Category A04 : Insecure Design
-
Clickjacking Defense in OWASP Cheat Sheet Series.