Iics Project Report
Iics Project Report
Team members:
Vamsi Krishna Koppala (R11941501)
Tirumalesh Adari (R11934483)
Yuvaraj Koniki (R11933516)
INDEX
ABSTRACT……………………………………………………………………………………..1
INTRODUCTION……………………………………………………………………………….2
WHAT IS CLICKJACKING…………………………………………………………………….4-5
IMPLEMENTATION……………………………………………………………………………6-8
CONCLUSION…………………………………………………………………………………14
ABSTRACT:
This project focuses on bolstering the security of web applications by fortifying defences against
clickjacking attacks, a deceptive technique where users unwittingly engage with concealed elements
on web pages. Clickjacking presents. The overarching aim of this endeavour is to provide a multi-
layered defence approach that encompasses both client-side and server-side protection mechanisms.
On the client side, techniques such as frame-busting scripts, Content Security Policy (CSP) headers,
and X-Frame-Options headers will be employed to prevent malicious embedding of web pages or
elements within iframes. These measures aim to ensure that users interact only with legitimate content
and are shielded from inadvertent engagement with hidden or malicious elements.
Complementing the client-side defences, server-side protections will be implemented to bolster the
resilience of web applications against clickjacking attempts. This includes measures such as
implementing server-side frame-busting techniques, employing server-side validation of user actions,
and enforcing strict access controls to mitigate the risk of unauthorized actions or data leakage.
By adopting a comprehensive security strategy that addresses both client-side and server-side
vulnerabilities, this project seeks to significantly reduce the likelihood and impact of clickjacking
attacks on web applications. Ultimately, the goal is to create a safer online environment for users,
where they can confidently interact with web applications without falling victim to deceptive tactics
employed by malicious actors. a substantial threat, as it can lead to unauthorized actions and
information disclosure.
1
INTRODUCTION:
2
Team Members Contribution:
• Testing the working of clickjacking with different websites and local hosts
• Implement Frame Busting for client-side protection.
• Implement X-Frame-Options for server-side protection.
• Research and implement Content Security Policy (CSP).
• Gathering content for the above-mentioned methods with examples for documentation.
Yuvaraj Koniki(R11933516):
Each member will be responsible for implementing their assigned tasks and ensuring their
effectiveness in enhancing the security of web applications against clickjacking attacks. Regular
communication and collaboration among team members will be essential to ensure smooth progress
and integration of all implemented measures.
3
What is Clickjacking:
Clickjacking is a malicious tactic that deceives users into interacting with a webpage element that
appears innocuous or is disguised as another element. This manipulation can lead users to unknowingly
initiate harmful actions, including downloading malware, visiting malicious websites, disclosing
sensitive information or credentials, transferring funds, or making unintended purchases online.
In a typical clickjacking scenario, an invisible webpage or HTML element is overlaid within an iframe
on top of the visible content that the user sees. Although users believe they are clicking on the visible
content, they are interacting with the hidden element contained within the overlaid page.
The obscured page can be either malicious, aiming to exploit user actions for nefarious purposes, or
legitimate but unintended by the user – for instance, a page on their online banking platform that
authorizes money transfers.
Various forms of clickjacking exist, including:
1. Likejacking:
This technique manipulates the Facebook "Like" button, causing users to
mistakenly "like" a page they did not intend to endorse.
2. Cursorjacking:
Cursorjacking is a UI redressing method that alters the perceived position of
the cursor to mislead users. This exploit capitalizes on vulnerabilities in Flash and older
versions of the Firefox browser, though these vulnerabilities have since been addressed.
4
Fig: Clickjacking Working
IMPLEMENTATION:
The command “python -m http.server” is used to start a simple HTTP server with Python. This
command is part of the Python Standard Library and serves files from the current directory and below,
making them accessible via a web browser at http://localhost:8000 by default.
5
Fig: Starting HTTP server using python
Code written in “app.py” to make the website accessible at http://localhost:5000 and to be protected
against clickjacking. The X-Frame-Options and Content-Security-Policy headers will prevent the page
from being framed.
6
Fig: app.py file
Created a template folder where the “app.py” is located and moved the “index.html” into it because
the flask by default looks for html files in template folder.
7
Fig: Flash package Installation
8
Observation:
As we see that, by using client-side protection methods such as X-Frame-Options and Content-
Security-Policy headers will prevent the page from being framed. So that, by using some of these
methods can prevent page from being vulnerable to clickjacking.
Client-Side Prevention:
1. Frame Busting:
Description: Frame busting involves embedding a script in each page that prevents the site from
being framed. The script typically contains conditional statements to detect if the page is loaded
within a frame and counteractions to break out of the frame.
Example:
JavaScript code:
if (top != self) {
top.location = self.location;
}
Explanation: This script checks if the current window is the top-level window. If not, it redirects the
top-level window to the same location as the current window, effectively breaking out of any framing.
2. Double Framing:
Description: Some frame-busting techniques may fail when the target page is framed within multiple
nested frames. Accessing parent.location in such scenarios can lead to security violations, disabling
the frame-busting counteraction.
Example:
Target site frame busting code (target site):
if(top.location!=self.location) {
parent.location = self.location;
}
Attacker’s top frame (fictitious2.html):
<iframe src="fictitious.html">
Attacker’s fictitious sub-frame (fictitious.html):
<iframe src="http://target site">
9
Explanation:
When a page is nested within multiple frames, accessing parent.location from inner frames may not
accurately reflect the top-level window's location, making it challenging to implement effective
frame-busting.
3. Disabling JavaScript:
Description:
Disabling JavaScript in a browser or employing techniques like restricted frames, sandbox attributes,
or design mode can undermine frame-busting protection, as these techniques rely on JavaScript
execution.
Example:
Target site frame-busting code:
html
<!DOCTYPE html>
<html>
<head>
<title>Frame Busting Example</title>
<script>
if (top !== self) {
top.location = self.location;
}
</script>
</head>
<body>
<h1>This page cannot be framed.</h1>
</body>
</html>
Attacker's page with JavaScript disabled:
html
<!DOCTYPE html>
<html>
<head>
10
<title>Attacker's Page</title>
</head>
<body>
<h1>JavaScript Disabled</h1>
<iframe src="https://www.example.com/page-with-frame-busting-script"></iframe>
</body>
</html>
Explanation:
When JavaScript is disabled in the browser, the frame-busting script on the target site will not
execute. As a result, the page can be loaded within an iframe without being redirected, bypassing the
frame-busting protection entirely. This underscores the importance of considering the limitations of
JavaScript-dependent security mechanisms.
4. OnBeforeUnload Event:
Description:
The OnBeforeUnload event can be exploited by attackers to bypass frame-busting code. They can use
this event to interfere with navigation requests, such as cancelling them or prompting users to confirm
leaving the page, thus undermining the effectiveness of frame-busting attempts.
Example:
Target site's frame-busting code:
html
<!DOCTYPE html>
<html>
<head>
<title>Frame Busting Example</title>
<script>
window.onbeforeunload = function() {
return "Are you sure you want to leave this page?";
};
</script>
</head>
<body>
<h1>This page cannot be framed.</h1>
</body>
11
</html>
Attacker's page exploiting OnBeforeUnload:
html
<!DOCTYPE html>
<html>
<head>
<title>Attacker's Page</title>
<script>
window.onbeforeunload = function() {
// Cancel the navigation request
return false;
};
</script>
</head>
<body>
<h1>Attacker's Page</h1>
<iframe src="https://www.example.com/page-with-frame-busting-script"></iframe>
</body>
</html>
Explanation:
In this example, the target site's frame-busting script triggers the OnBeforeUnload event, which
prompts users to confirm leaving the page. However, the attacker's page overrides this behaviour by
defining its own OnBeforeUnload event handler that cancels the navigation request, effectively
preventing the frame-busting script from redirecting the page. This manipulation allows the attacker to
load the target page within an iframe, bypassing the frame-busting protection mechanism.
5. XSS Filter:
Description:
XSS filters in browsers, such as IE8's XSS filter and Chrome's XSS Auditor, are designed to detect
and prevent cross-site scripting attacks by sanitizing or blocking potentially malicious scripts.
However, these filters can be exploited by attackers to disable frame-busting code by causing false
positives or specifically targeting the frame-busting script.
Example:
Target site's frame-busting code:
html
12
<!DOCTYPE html>
<html>
<head>
<title>Frame Busting Example</title>
<script>
if (top !== self) {
top.location = self.location;
}
</script>
</head>
<body>
<h1>This page cannot be framed.</h1>
</body>
</html>
Attacker's injected script with XSS payload:
html
<!DOCTYPE html>
<html>
<head>
<title>Attacker's Page</title>
</head>
<body>
<h1>Attacker's Page</h1>
<script>
// Malicious XSS payload targeting frame-busting script
var payload = '<script>top.location = self.location;</script>';
// Injecting the payload into the vulnerable page
document.write('<iframe src="https://www.example.com/page-with-frame-busting-
script"></iframe>');
</script>
</body>
13
</html>
Explanation:
In this scenario, an attacker injects a malicious XSS payload into a vulnerable page. This payload
specifically targets the frame-busting script by attempting to set the top-level window's location to the
current location. The XSS filter in the browser may fail to detect this payload as malicious, allowing it
to execute successfully and disable the frame-busting protection. As a result, the target page may be
loaded within an iframe despite attempts to prevent framing, highlighting the potential for XSS filters
to inadvertently undermine security measures like frame busting.
CONCLUSION:
This comprehensive approach combines client-side and server-side defences, encompassing a range of
techniques to mitigate clickjacking risks effectively. The project aims to bolster the security posture of
web applications, providing a robust defence against deceptive attacks.
14