While doing some testing for a client, I was testing an application that had a console interface which allowed a user to grab credentials for their account and any other account they had access to. Due to how this application was configured, it was vulnerable to click jacking.
Clickjacking, or UI redress attacks, occur when an attacker tricks a user into clicking on hidden elements within an iframe or transparent layers, leading to unintended actions on another site. For example, a user might click a visible button but unknowingly trigger a hidden action, such as deleting emails or changing security settings. Keystroke jacking is a related attack where an attacker steals input typed into invisible forms.
To defend against clickjacking, sites can use HTTP headers like X-Frame-Options or Content Security Policy’s frame-ancestors directive, which restrict the ability to embed content within iframes. Additionally, setting cookies with the SameSite attribute can prevent session cookies from being used in cross-site frames, thwarting some clickjacking attempts. Implementing JavaScript frame-busting scripts provides extra protection, ensuring that pages cannot be loaded in unauthorized iframes. However, attackers have developed techniques to bypass these defenses, such as using nested frames or exploiting browser-specific vulnerabilities, making it essential to use a defense-in-depth approach.
The application I was testing did not have these defense mechanisms and was vulnerable. To test for this vulnerability I tried two different things. I first used this basic template script that is a very crude way to see if an application is vulnerable to click jacking.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Clickjacking Test</title>
<style>
iframe {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
opacity: 0.7; /* Semi-transparent iframe */
z-index: 1;
}
.click {
position: absolute;
top: 50px;
left: 50px;
width: 200px;
height: 50px;
z-index: 2;
opacity: 0; /* Transparent clickable button */
}
</style>
</head>
<body>
<h1>Clickjacking Test</h1>
<p>If the iframe below loads and the button can be clicked, the site might be vulnerable to clickjacking.</p>
<iframe src="https://target-site.com" frameborder="0"></iframe>
<!-- Invisible button over the iframe -->
<button class="click" onclick="alert('Button clicked! Possible clickjacking vulnerability.')"></button>
</body>
</html>I could see that I could frame the target application in my own iframe that I was hosting locally on a python server. Next, I used a feature that is built into Burp Suite (maybe just pro, not sure) called clickbandit that will let you copy/paste some javascript to make a better proof of concept. You put this javascript into the browser console and it will load a script that will let you create some html/css with a targeted click on the target website.
https://portswigger.net/burp/documentation/desktop/tools/clickbandit
After making my PoC, I was able to show that this application was vulnerable by placing the exploitative click over the same button on the target website that would dispense credentials. This was a great find. However, click jacking is normally considered a low to medium finding because it requires social engineering to get someone to visit your fake website “clone”.
I managed to raise this finding to a high because this application was also missing a Content Security Policy and would allow cross origin requests from any domain. I was able to modify my PoC to show that my fake clone website could harvest credentials as the user by making requests on their behalf to the vulnerable web application. It was a social engineering attack still but the most dangerous kind and because this was considered a national security application, the high finding was easily accepted.