<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Clickjacking on an's security blog</title><link>https://panman4040.github.io/training/portswigger/clickjacking/</link><description>Recent content in Clickjacking on an's security blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 15 Jul 2026 08:36:00 +0700</lastBuildDate><atom:link href="https://panman4040.github.io/training/portswigger/clickjacking/index.xml" rel="self" type="application/rss+xml"/><item><title>Exploiting clickjacking vulnerability to trigger DOM-based XSS | &lt;span style="color:#3498db">Practitioner&lt;/span></title><link>https://panman4040.github.io/training/portswigger/clickjacking/cj_practitioner1/</link><pubDate>Wed, 08 Jul 2026 13:46:16 +0800</pubDate><guid>https://panman4040.github.io/training/portswigger/clickjacking/cj_practitioner1/</guid><description>&lt;p>As the lab&amp;rsquo;s name suggests, there exists a DOM-XSS vulnerability somewhere in the application. Naturally, we should crawl through the site and see where does a vulnerable DOM sink lives. The feedback form is looking a bit fishy so let&amp;rsquo;s check that out!
&lt;img src="https://panman4040.github.io/images/viber_image_2026-07-08_13-30-36-341.png" alt="">
Looks like our intuition is correct! Whatever passed into the &lt;code>name&lt;/code> field &lt;em>will be&lt;/em> reflected in the &lt;code>innerHTML&lt;/code> sink after submission. And it looks like the application doesn&amp;rsquo;t filter out angle brackets or quotes, which makes constructing XSS payloads much easier. Let&amp;rsquo;s test this out by injecting a harmless &lt;code>h1&lt;/code>:
&lt;img src="https://panman4040.github.io/images/viber_image_2026-07-08_13-33-07-835.png" alt="">
The parser indeed recognises this as valid HTML, and display it proudly. Since our sink is &lt;code>innerHTML&lt;/code>, we have to use &lt;code>img&lt;/code> or &lt;code>iframe&lt;/code> to fire our events. Testing with the &lt;code>&amp;lt;img src=1 onerror=print()&amp;gt;&lt;/code> payload will do its job as told.&lt;/p></description></item><item><title>Clickjacking with a frame buster script | &lt;span style="color:#2ecc71">Apprentice&lt;/span></title><link>https://panman4040.github.io/training/portswigger/clickjacking/cj_apprentice1/</link><pubDate>Wed, 08 Jul 2026 10:18:16 +0800</pubDate><guid>https://panman4040.github.io/training/portswigger/clickjacking/cj_apprentice1/</guid><description>&lt;p>First of all, in order for a clickjacking attempt that changes victim&amp;rsquo;s states to work, anything that requires cookie auth must have that cookie set &lt;code>SameSite=None&lt;/code>. Thankfully, this is indeed the case for this lab:
&lt;img src="https://panman4040.github.io/images/viber_image_2026-07-08_10-05-08-515.png" alt="">
Upon checking the source code, we can see that the developer tries to prevent clickjacking by adding a frame busting script as shown here. What this does is that it checks if the top-most window is the same as the current window. If they are different, it means the page is inside an iframe and the attempt is blocked:
&lt;img src="https://panman4040.github.io/images/viber_image_2026-07-08_10-04-57-242.png" alt="">
If we try to use &lt;a href="https://portswigger.net/burp/documentation/desktop/tools/clickbandit">Burp Clickbandit&lt;/a>, notice that the attempt to frame the site is blocked:
&lt;img src="https://panman4040.github.io/images/viber_image_2026-07-08_10-07-01-757.png" alt="">
To solve this, we should also strip &lt;code>allow-scripts&lt;/code> so that the framed page&amp;rsquo;s JavaScript will be blocked. &lt;code>allow-forms&lt;/code> is still kept because we need a form to change emails with (lol)
&lt;img src="https://panman4040.github.io/images/viber_image_2026-07-08_10-07-15-768.png" alt="">
After that, use Clickbandit to generate a sample PoC and deliver it to the victim. Neat&lt;/p></description></item></channel></rss>