Jorian
banner
jorianwoltjer.com
Jorian
@jorianwoltjer.com
Normalize being weird.
The author of the challenge, dari1wastaken, got the idea from this paper. Great results on internet-exposed servers:
www.ndss-symposium.org/ndss-paper/a...
A Large-Scale Measurement Study of the PROXY Protocol and its Security Implications - NDSS Symposium
www.ndss-symposium.org
November 16, 2025 at 1:59 PM
(5/5) For Client-Side Race Conditions based on network requests, you can slow down time by holding up the Connection Pool. Then slowly release them one by one, performing any actions you need in between with 100% consistency.
October 17, 2025 at 8:43 AM
(4/5) Form input history is restored on history.back() even if the HTML changed in the meantime.
For inputs without a form, that means you can hijack it into your own form with a form= attribute as an exception. From there you could submit your form to leak it.
October 17, 2025 at 8:43 AM
(3/5) Script gadgets inside an <iframe srcdoc> that require URL parameters can be set using a <meta http-equiv="refresh"> redirect to about:srcdoc. It reloads the document with the new URL while keeping its content.
October 17, 2025 at 8:43 AM
(2/5) With a strict CSP, .click() gadgets can be very useful for things like:
* Opening the attacker's website with <a target="_blank">
* Submitting a form for CSRF
* Performing actions on the site to trigger other behavior
October 17, 2025 at 8:43 AM
Forgot to add what we leak, this is the result:
September 16, 2025 at 10:42 AM
On our attacker's page, we load this in an iframe and can then access [0] to get a reference to our injected object. To read its name, we can set its location to *our* about:blank and then read the .name window property (set by the attribute)!
September 16, 2025 at 8:08 AM
Final exploit code:
gist.github.com/JorianWoltje...
Thanks Omid sharing this challenge!
September 13, 2025 at 6:10 AM
We first duplicate our page, then navigate the first tab to the target. From our 2nd tab, the iframe can now access `top.opener` to send a message to the target. Quickly after, the parent removes the iframe and the `event.source` becomes `null`.
September 13, 2025 at 6:10 AM
In our exploit we can do the same:
1. Create a same-origin iframe
2. Make the iframe send a message to the target window
3. Instantly remove the iframe from the DOM

There's a few ways to get a reference to the target window from inside the iframe, but I used `opener` as follows:
September 13, 2025 at 6:10 AM
The solution comes from an obscure 2012 discussion where the developer noticed it being `null` in a bug:
groups.google.com/a/chromium.o...
They let an iframe send a message, and the iframe element was removed right after. By the time the receiver handles it the source is gone!
Can the source of a MessageEvent ever be undefined?
groups.google.com
September 13, 2025 at 6:10 AM
We can read that for `undefined` to be loosely equal to something, the other must be either `null` or `undefined`:
developer.mozilla.org/en-US/docs/W...
So how could we potentially unset `event.source` for our malicious message?
Equality (==) - JavaScript | MDN
The equality (==) operator checks whether its two operands are equal, returning a Boolean result. Unlike the strict equality operator, it attempts to convert and compare operands that are of different...
developer.mozilla.org
September 13, 2025 at 6:10 AM
The main hurdle to overcome is `event.source != window.message_frame?.contentWindow`. The `?.` makes the comparison `undefined` if window.message_frame doesn't exist, which is the case if the user hasn't clicked yet.
Loosely comparing to undefined is all that's protecting it now?
September 13, 2025 at 6:10 AM
(for people having trouble recognizing sarcasm online, this is a joke, I'm not actually becoming a like farmer)
August 1, 2025 at 7:43 PM