UI Redressing
Play Labs on this vulnerability with SecureFlag!
Description
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.
Another instance of this issue may originate from a CSS injection exposure. It might be the case that a vulnerable application allows some forms of code injection in such a way that it’s not possible to obtain a proper XSS impact; rather, the injection point happens inside (and without the possibility of escaping from) a <style> tag. If that is the case, the attacker might have full control over the style of the web page displayed by the victim. One interesting way to exploit this is to make the target web page look like something else by, for example, rearranging, hiding, or otherwise altering the style of the existing components in such a way that the result is something that the victim would click or interact with. It’s important to remember that, just like the above scenario, the attacker cannot trick the victim into performing an action that isn’t already present in the legitimate page. The prevention, in this case, is obviously to get rid of any chance of injection.
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.
Impact
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, 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.
Scenarios
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.
Prevention
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:
-
X-Frame-Optionsset toDENY,ALLOW-FROM <origin>orSAMEORIGIN. This is supported by major browsers but has been deprecated in favor of CSP (Content Security Policy). -
Content-Security-Policyset toframe-ancestors 'none',frame-ancestors <origin>orframe-ancestors 'self'.
Testing
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.
- OWASP ASVS: 14.4.7
- OWASP Testing Guide: Testing for Clickjacking