Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Self-XSS is when you can trigger cross site scripting (XSS) but only on yourself. This post goes into a few ways to make self-XSS exploitable, with the final one being the most interesting.

The main topic of discussion is credentialless iframes. A credentialness iframe is an iframe that is loaded inside of a different context than those on the same origin. Since iframes on the same origin is able to edit other frames on other origins, it's able to edit the logged in iFrame still.

If the page contains login CSRF then the usage of credentialless iframes becomes useful.

1. Create a login CSRF attack on a victim and get the victim to visit the website.
2. On the same page with the login CSRF to a page that contains two iFrames: one with the credentialless iFrame and another with the regular user login.
3. Use the XSS on the credentialless iFrame to write into the context of the other iFrame. This leads to many security issues.

The second idea is using clickjacking to trick a user to login to an account instead. This works when CSRF login is not possible. Both of the previous techniques require iframes to be allowed on a page though.

The coolest example is the final one, by far. In 2025 the function fetchLater function was added. This will send requests after some time, even if the tab is closed. This means it may be possible to do the following:

1. Trigger self-XSS on an account you control.
2. Call fetchLater for a fetch requests that uses cookies for a sensitive API.
3. Logout of the account.
4. User logs into the account later.
5. The fetchLater request runs in the context of the users session. This is an easy account takeover from here!

On the Critical Thinking podcast, the host Justin claims that the closing at Chrome will shoot off all the requests, making it not good for . To get around this, an attacker can stall the HTTP response on a server that they control with maximum length timeouts in Chrome and redirects. Eventually, the redirect can go to a malicious endpoint on the regular server from the context of the Chrome request. I think that the redirect will lead to a resubmission of the cookies, such as the new cookies of the logged in user. Pretty neat!