Clickjacking is the attack that tricks a user into clicking a Webpage element that is invisible or disguised as another element. Users can unwittingly download malware, visit malicious web pages, provide credentials or sensitive information, send money, or make purchases online as a result of this.
Typically, Clickjacking is performed by displaying an invisible page or HTML element, inside an iframe, on top of the page the user sees. The user believes they are clicking the visible page but in fact, they are clicking an invisible element in the additional page transposed on top of it.
Using a similar technique, keystrokes can also be hijacked. A user will be led to think they are typing into their email or bank account password when they are instead typing into an invisible frame operated by the intruder using a specially designed mix of stylesheets, iframes, and text boxes.
Examples: Imagine an attacker who builds a website that has a button on it that says, “click here for a free iPhone”. However, on top of that web page, the attacker has loaded an iframe with your mail account and lined up exactly the “delete all messages” button directly on top of the “free iPhone” button. The victim tries to click on the “free iPhone” button but instead actually clicked on the invisible “delete all messages” button. The attacker has effectively “hijacked” the user’s click, hence the term “Clickjacking”.
In order to exploit this vulnerability, the attacker would place an iframe with the malicious link behind a valid actionable button and make it transparent to capture the clicks.
Steps to Reproduce:
- First, create an Html page that will check that the website(https://demo.testfire.net/index.jsp) is vulnerable to clickjacking or not.
Here is the code. Copy the code and create a html file.
|<html><head><title>Clickjack test page</title></head><body><p>Website is vulnerable to Clickjacking!</p><iframe src=”https://demo.testfire.net/”width=”500″ height=”500″></iframe></body></html>|
- Open the file in the browser and check the result.
- If the text “Website is vulnerable to clickjacking” appears and below it you see the content of your sensitive page, the page is vulnerable to clickjacking.
- If only the text “Website is vulnerable to clickjacking” appears, and you do not see the content of your sensitive page, the page is not vulnerable to the simplest form of clickjacking.
Most popular clickjacking attacks involve framing the targeted web page in an iframe at some stage, so all the main prevention methods aim to disallow framing. Legacy solutions used client-side scripts to break pages out of frames, while more modern and secure approaches rely on setting HTTP security headers to specify framing policy:
- Framebusting or framebreaking: Prior to the widespread adoption of new HTTP headers, website developers were on their own and had to rely on framebuster (or framekiller) scripts to save their pages from being framed. The first Framebusting scripts simply checked top.Location to make sure this was the current page – if not, top.Location was set to self. However, these scripts could easily be blocked from the outer frame or otherwise bypassed, and more elaborate solutions were developed. Even so, numerous ways of bypassing even the most elaborate frame breakers exist, and such scripts should only be used to provide rudimentary protection for legacy browsers. The approach currently recommended by OWASP is to hide the entire body of the HTML document and only show it after verifying that the page is not framed.
- X-Frame-Options: Using the X-Frame-Options (XFO) HTTP response header in server responses is probably the best approach right now. Originally introduced by Microsoft in Internet Explorer 8 and later formalized in RFC 7034, the X-Frame-Options header is used to specify whether a page can be embedded in a <frame>, <iframe>, <embed> or <object> element. The header supports three possible directives: deny to block all framing attempts, same-origin to allow framing only by pages of the same-origin or allow-from to allow framing by pages from specified URIs. Allow-from, on the other hand, is not supported by most browsers (including Chrome and Safari), so if you need to define sources, you should use CSP instead (see below). For general anti-framing protection, you only need to specify X-Frame-Options: deny or X-Frame-Options: same-origin in your server’s headers.
- Content-Security-Policy with frame-ancestors: The Content-Security-Policy HTTP header (CSP) was created to defend against cross-site scripting (XSS) and other data injection attacks. However, it also provides a frame-ancestors directive for specifying sources that are permitted to embed a page.
The syntax is simple: Content-Security-Policy: frame-ancestors <source1> <source2> … <sourceN>;
Apart from anti-framing schemes on the server-side and client-side, users are also protected from clickjacking by security features built into modern browsers Multiple layers of tests are used during the web page rendering process to ensure that user interfaces behave as intended, including anti-clickjacking algorithms to prevent repositioning, and scrolling attacks. Browsers can also block pop-ups and other odd web page habits, as well as warn users when suspicious operations are attempted.
Get In Touch
How Can We Help ?
We make your product happen. Our dynamic, robust and scalable solutions help you drive value at the greatest speed in the market