x0root

Overview We pat ourselves on the back when our WAF blocks a classic <script> alert. But modern web applications are a tapestry of first-party code and third-party services. What happens when an attacker doesn't need to break your walls, but simply uses a door you left open for a trusted guest? The Vulnerability Let's set the scene. Your application, trusted-site.com, has secure server-side filters. It correctly neutralizes or blocks any user input containing <script>, onerror=, or other obvious XSS vectors. However, to support rich content, you allow certain HTML tags like <iframe> and <object>. These are necessary for embedding videos, maps, or other third-party widgets. An attacker discovers this policy. They don't try to inject JavaScript directly. Instead, they inject a gateway: <iframe src="https://vulnerable-widget-provider.com/page-with-xss.html" style="position:fixed;top:0;left:0;width:100vw;height:100vh;border:none;"...

My interest in cybersecurity started when I was a kid, though I didn't fully realize it at the time. I spent a lot of time playing online games and would often run into cheaters. It was frustrating, but it also made me curious. How were they doing it? My research led me to discover that cheats were often made with code, particularly in Java. This sparked my interest, and soon I was experimenting with Cheat Engine. Seeing how things worked behind the scenes was fascinating and made me want to learn more about how computers and software functioned. My exploration eventually led me to web development, but cybersecurity always grabbed my attention the most. When I was around 8 or 9, I noticed a security weakness on my school's website involving easily guessable credentials. Gaining that firsthand view of how predictable information could be exploited felt like my first lesson in security and social engineering. That moment pushed me to learn even more. I started digging into diffe...