Leaky Jar — Intigriti Challenge Write-up

Leaky Jar is where bakers share their best cookie recipes — and argue about them in the reviews. Find your next favourite.

Published: 2026-06-30
Authors: asako
Updated: 2026-06-30
Category: Web
📖 2 min read

Leaky Jar — Intigriti CSRF challenge

Leaky Jar homepage

Leaky Jar is a small recipe-sharing app for "bakers". Log in and you get your own private recipe box. You can add recipes to it, share the whole box with another baker by username, or report a recipe URL to the Master Baker — an admin bot that opens whatever link you send while logged into its own account.

That last feature is where things get interesting. The Master Baker's box holds the flag, stored as the "Master Baker's Secret Recipe", and there's no direct path into the admin's box. So the challenge boils down to one question: how do you read a recipe that lives in someone else's vault?

Three actions matter here:

  • POST /share — share your entire box with another baker
  • POST /recipe — add a recipe to your box
  • POST /report — get the admin bot to visit a URL

The bug

Open the state-changing requests in Burp and the problem shows up fast. Neither /share nor the add-recipe endpoint has any CSRF protection:

  • No anti-CSRF token. The body is just username=<whoever>, completely predictable.
  • No Origin or Referer check, so a request from any site is accepted.
  • The session cookie is set with SameSite=None, so the browser attaches it to cross-site POSTs too.

The POST /share request in Burp

Put those three together and it's a textbook CSRF: get the victim's browser to fire a forged POST and it runs in their session. We don't even have to figure out delivery — "Report a recipe" is literally built to hand a URL to the logged-in admin.

Which means this goes past "make the admin click something". We can make the admin share its secret box with us.

Building the exploit

First I registered a plain baker account, asako. That's who the admin is going to end up sharing with.

Registering the asako account

Then a one-page site with a hidden form that auto-submits a share request naming asako as the recipient. When the admin loads the page, its cookie rides along and the box gets shared with me.

<!doctype html>
<html>
  <body>
    <form id="f" action="https://leakyjar.intigriti.io/share" method="POST">
      <input type="hidden" name="username" value="asako">
    </form>
    <script>document.getElementById('f').submit();</script>
  </body>
</html>

Host it anywhere you control — Beeceptor, ngrok, a static host, take your pick.

Now hand it over. Paste the URL into Report a recipe and send it to the Master Baker.

shutuptakemycsrf Reporting the URL to the Master Baker

The server confirms it's queued:

Report queued confirmation

The bot opens the page in its authenticated session, the hidden form submits, and POST /share goes out with the admin's cookie attached. The admin shares its private box with asako without any interaction on its end.

Last step: log back in as asako and go to My recipe box → Shared with you. The admin's box is sitting right there. Open it and the Master Baker's Secret Recipe is fully readable. The "share my recipe box" form The admin's box disclosed, flag visible

Flag

INTIGRITI{019ef404-1e44-7748-bdcf-ca7b12dbfee0}

Challenge solved

Why it works

No CSRF protection plus a SameSite=None cookie is all it takes to push any logged-in baker, admin included, into actions they never agreed to — just by getting them to open a page. And the app hands you a delivery mechanism for free. In practice that's enough to read someone's entire private vault (the flag, here) or quietly write recipes into a box that isn't yours.