0% found this document useful (0 votes)
29 views

Iics Project Report

Uploaded by

Motion Pictures
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views

Iics Project Report

Uploaded by

Motion Pictures
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

Project Report:

Project Shield: Safeguarding Against


Deceptive Attacks using Clickjacking.

Team members:
Vamsi Krishna Koppala (R11941501)
Tirumalesh Adari (R11934483)
Yuvaraj Koniki (R11933516)
INDEX

ABSTRACT……………………………………………………………………………………..1

INTRODUCTION……………………………………………………………………………….2

TEAM MEMBERS CONTRIBUTION………………………………………………………….3

WHAT IS CLICKJACKING…………………………………………………………………….4-5

IMPLEMENTATION……………………………………………………………………………6-8

METHODS TO PREVENT CLICKJACKING…………………………………………………9

CLIENT-SIDE PREVENTION METHODS……………………………………………………9-14

WHAT NEEDS TO BE DONE IN PHASE-2…………………………………………………..14

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:

In contemporary cybersecurity landscapes, the protection of web applications is of paramount


importance, given the evolving sophistication of cyber threats. Among these threats, clickjacking
emerges as a particularly insidious technique, leveraging deception to manipulate users into interacting
unknowingly with obscured elements embedded within web pages. This deceptive practice poses a
significant risk to the integrity and security of online platforms. Thus, the primary objective of this
project is to bolster the defences of web applications against clickjacking attacks through the
implementation of robust protective measures.
Clickjacking operates by exploiting the trust users place in the visual elements of web pages. By
concealing malicious content behind seemingly innocuous interfaces, attackers can trick users into
performing unintended actions, potentially resulting in unauthorized access or the inadvertent disclosure
of sensitive information. Recognizing the severity of this threat, this project endeavours to address
clickjacking vulnerabilities comprehensively by deploying both client-side and server-side protection
mechanisms.
On the client side, measures will be implemented to fortify the user's browser environment against
clickjacking exploits. Techniques such as frame-busting scripts, Content Security Policy (CSP) headers,
and X-Frame-Options headers will be employed to prevent the illicit embedding of web content within
iframes, thereby safeguarding users from unwittingly interacting with concealed elements.
Simultaneously, server-side defences will be deployed to augment the security posture of web
applications against clickjacking attacks. These measures may include the implementation of server-
side frame-busting techniques, rigorous validation of user actions, and the enforcement of stringent
access controls to mitigate the risk of unauthorized activities or data exposure.
By adopting a multi-faceted approach that addresses vulnerabilities at both the client and server levels,
this project aims to significantly reduce the susceptibility of web applications to clickjacking exploits.
Through the implementation of robust protective measures, the integrity, confidentiality, and
trustworthiness of online platforms will be enhanced, fostering a safer digital environment for users and
organizations alike.

2
Team Members Contribution:

Vamsi Krishna Koppala(R11941501):

• 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):

• Implement Mobile Website Version for client-side protection.


• Research and implement Proxies for server-side protection.
• Research about the Subresource Integrity (SRI).
• Implement the Subresource Integrity with examples.
• Documentation preparation and explanation of methods.

Tirumalesh Adari (R11934483):

• Implement Double Framing for client-side protection.


• Implement Browser Compatibility for server-side protection.
• Research and implement OnBeforeUnload Event for client-side protection.
• Research about disabling JavaScript method.
• Power Point Presentation preparation.

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.

How Clickjacking Works:

1. Creating the malicious page:


The attacker creates a web page with a hidden iframe containing a button
from another website that the user is likely to be authenticated on (like a “delete all messages” button
on an email website).
2. Overlaying the button:
The attacker overlays the button with a harmless-looking clickable element
on their own page, such as a link that says, “Click here to win $100!”.
3. Tricking the user:
When the user clicks on the link, they’re clicking on the invisible button in the
iframe. This could lead to unwanted actions being performed on the other website on behalf of the
user.
4. Collecting information:
Depending on the nature of the button, the attacker could potentially
collect sensitive information, perform actions on behalf of the user, or even take over the user’s
account.

4
Fig: Clickjacking Working

IMPLEMENTATION:

Checking whether the site is vulnerable to ClickJacking or not:

Step 1: Creating a sample website

Fig: Simple website

Then run the server using python terminal

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

Website is loaded from the localhost:8080

Fig: Loading website

Test whether the website is vulnerable to Clickjacking or not:

Fig: Testing Vulnerability

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.

Fig: Index file location

Installing flash package:

7
Fig: Flash package Installation

Running the app.py:

Fig: Running app.py

Now, our website is accessible at http://localhost:5000:

Fig: Vulnerability Testing


Again, we tested for the vulnerability, but as you can see, our website is not loaded into the frame this
time.

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.

Methods to Prevent Clickjacking:

To prevent clickjacking effectively, a combination of client-side and server-side measures is typically


employed. Here are some techniques to prevent 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.

WHAT NEEDS TO BE DONE FOR THE PHASE 2:

• Implement additional methods in client-side protection.


• server-side protection implementation with the accurate description.
• Implementing additional methods such as CSP and Sub Resource Integrity.
• Analysing the methods by comparing and determining the efficient methods.
• Observing the differences and new learning outcomes during the project implementation.
• Concluding the project with accurate and absolute output.

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

You might also like