Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

LeakyJar: Zero-Click CSRF Leads to Disclosure of Master Baker's Private Recipe Box

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

Target Overview

The Leaky Jar challenge application (leakyjar.intigriti.io) is a cookie-recipe sharing site. Authenticated users land on a homepage with navigation to Recipes, Bakers, "My recipe box," and "Report a recipe," shown below for context.

Summary

The /share endpoint, which allows a logged-in baker to share their recipe box with another user, is vulnerable to Cross-Site Request Forgery. The endpoint accepts a single username parameter via POST with no anti-CSRF token, no Origin/Referer validation, and a session cookie that is sent on cross-site form submissions. By hosting a self-submitting HTML form and reporting it through the in-app "Report a recipe" / review feature, an automated reviewer bot (acting with the privileges of the admin / "Master Baker" account) visited the page and was forced to share admin's recipe box with an attacker-controlled account — with zero clicks or interaction from the victim beyond loading the page. The attacker account then read admin's recipe box directly and retrieved the flag.

Vulnerability

Endpoint: POST /share Parameter: username (the account to share the victim's recipe box with)

Example legitimate request:

Server response:

The request:

  • Contains no CSRF token in the body, headers, or as a double-submit cookie.

  • Is accepted regardless of Origin/Referer header values.

  • Relies solely on the session cookie for authentication, which is attached automatically by the browser on a cross-site form POST triggered from a third-party page.

This allows any page on the internet to force a logged-in victim's browser to issue a /share request on their behalf, sharing the victim's recipe box with an arbitrary attacker-chosen account, without the victim's knowledge or consent.

Impact

Because the in-app review/report feature is fulfilled by an automated bot that browses the submitted URL while authenticated as admin ("the Master Baker"), this CSRF can be weaponized to compromise the admin account's data with zero user interaction: the bot only needs to load the attacker's page, and the form auto-submits via onload.

This results in unauthorized disclosure of admin's private recipe box, which contains the challenge flag.

Steps to Reproduce

  1. Register an attacker-controlled account.

    Response: 302 /vault, with a fresh session cookie issued for attacker_recon.

  2. Host the zero-click CSRF PoC on attacker-controlled infrastructure (verified publicly reachable, HTTP 200):

    http://IP:PORT/csrf_share_poc.html

    This form requires no click — it submits itself the instant the page finishes loading in any browser that already holds an authenticated Leaky Jar session.

  3. Submit the PoC URL to the Master Baker via the in-app reporting feature, authenticated as attacker_recon:

    Response: HTTP 200, body confirms: "Sent — the Master Baker will check it shortly." (13:44:08 UTC)

  4. Confirm the bot visited the PoC. Attacker-controlled server access log:

    The visit occurred ~3 seconds after submission, from a Google Cloud IP range — consistent with an automated headless-browser reviewer fetching and rendering the reported URL while authenticated as admin. (This is inferred from timing, IP provenance, and the resulting state change below; the bot's internal session handling is not directly observable from the attacker side.)

  5. Confirm impact — re-check the attacker's vault immediately after:

    The "Shared with you" section now lists a new entry, "admin's recipe box," linking to /vault/1ff08922-d80e-4b92-9fd8-67e0d3a5e988 — an entry that did not exist prior to step 3 (only test123's box was previously shared).

  6. Retrieve the flag from admin's now-shared recipe box:

    Response body includes:

Root Cause

  • /share performs no CSRF protection (no token, no SameSite=Strict cookie enforcement effective against this flow, no Origin/Referer check).

  • The automated report-review bot loads attacker-supplied URLs while authenticated with elevated (admin) privileges, turning a same-origin CSRF bug into a remotely triggerable, zero-click privilege issue against the admin account specifically.

Remediation Recommendations

  • Implement per-session CSRF tokens on all state-changing endpoints (/share, /vault/add, etc.), validated server-side on every POST.

  • Set the session cookie with SameSite=Strict (or Lax at minimum) and Secure.

  • Validate Origin/Referer headers on state-changing requests as a defense-in-depth measure.

  • Have the report-review bot browse submitted URLs in an isolated context without the admin's authenticated session, or strip cookies/use a sandboxed unauthenticated profile when rendering untrusted, user-submitted URLs.

Compliance with Challenge Rules

  • Leverages a vulnerability on the challenge page (/share CSRF). ✅

  • Not self-XSS, not MITM. ✅

  • No user interaction beyond the Master Baker bot loading the reported URL (auto-submitting form, zero clicks). ✅

  • No brute-forcing involved. ✅

PreviousIceBreaker 2: Mini-CTF ChallengeNextCTF@CIT 2025

Last updated