How I Solved Intigriti’s LeakyJar Challenge: One-click CSRF to Expose the Master Baker’s Private…

Intigriti's LeakyJar challenge was a CTF-style web security challenge focused on finding a valid vulnerability in a small recipe-sharing application and using it to recover the hidden flag.

The winning path I found was a one-click Cross-Site Request Forgery vulnerability in the recipe box sharing functionality. By abusing the missing CSRF protection on the /share endpoint, I was able to force the authenticated Master Baker bot to share its private recipe box with my attacker-controlled account.

Once the recipe box was shared, the flag became accessible through normal application functionality.

Final flag:

text 7 INTIGRITI{019ef404–1e44–7748-bdcf-ca7b12dbfee0}

This write-up walks through the full exploit chain, the vulnerable behavior, the payload, and the security lesson behind the bug.

Target

The challenge application was hosted at:

text https://leakyjar.intigriti.io/

The vulnerable endpoint was:

text POST https://leakyjar.intigriti.io/share

The affected feature was the authenticated recipe box sharing functionality inside the user vault.

High-level Summary

The application allowed authenticated users to share their private recipe box with another user by submitting a POST request containing only the recipient's username.

The request looked like this:

http POST /share HTTP/1.1 Host: leakyjar.intigriti.io Content-Type: application/x-www-form-urlencoded

username=ATTACKER_USERNAME

The problem was that this sensitive state-changing action did not require an anti-CSRF token.

Because of that, an attacker could host an external HTML page that automatically submitted the same POST request. If the authenticated Master Baker bot visited that page, the forged request would be sent with the bot's active session, causing the Master Baker's recipe box to be shared with the attacker.

Understanding the Application Flow

After creating an account and logging in, the application exposed a vault page where recipes were stored.

The relevant page was:

text https://leakyjar.intigriti.io/vault

Inside the vault, there was a feature called something equivalent to:

text Share my recipe box

This allowed one user to share their recipe box with another baker by entering a username.

From an attacker's perspective, this feature immediately stood out because sharing a private recipe box is an authorization-sensitive action. If abused, it could expose data that should remain private.

The next step was to understand how the sharing request worked.

The Vulnerable Request

The sharing feature submitted a POST request to:

text /share

with a single parameter:

text username=<recipient_username>

A simplified version of the request looked like this:

http POST /share HTTP/1.1 Host: leakyjar.intigriti.io Content-Type: application/x-www-form-urlencoded

username=noxzzdvnmbse9

The key observation was what the request did not include:

text No CSRF token. No unpredictable nonce. No confirmation token. No server-side proof that the request originated from the legitimate LeakyJar UI.

This meant the endpoint was potentially vulnerable to Cross-Site Request Forgery.

Root Cause

The root cause was missing CSRF protection on an authenticated state-changing endpoint.

The /share endpoint modified access control state by granting another user access to the current user's private recipe box. However, the server trusted the user's authenticated session alone.

That is dangerous because browsers may include a user's cookies when submitting eligible cross-site requests to the target origin.

In this case, if the Master Baker bot was authenticated to LeakyJar and then visited an attacker-controlled page, that page could submit a form to LeakyJar. The browser would attach the Master Baker's session cookies, and the server would process the request as the Master Baker.

Exploit Strategy

The challenge also provided a way to submit a URL to the Master Baker for review.

That created the complete attack path:

1. Register an attacker account.
2. Identify the recipe box sharing endpoint.
3. Confirm that /share does not require a CSRF token.
4. Host an external page with an auto-submitting HTML form.
5. Set the hidden username value to the attacker's username.
6. Submit the malicious page URL to the Master Baker bot.
7. Wait for the bot to visit the page.
8. The bot's browser submits the forged /share request while authenticated.
9. The Master Baker's recipe box becomes shared with the attacker.
10. Log back in as the attacker and open the shared recipe box.
11. Retrieve the flag.

The CSRF Payload

The generic payload was simple:

html

Loading recipe…

document.getElementById('f').submit(); </script>

The payload used in the successful solve was:

html

Loading recipe…

document.getElementById('f').submit(); </script>

The attacker username used was:

text noxzzdvnmbse9

When the page loads, the JavaScript immediately submits the form to the vulnerable /share endpoint.

Step-by-step Exploitation

Step 1: Create an attacker account

First, I registered a normal user account on the challenge application.

Registration endpoint:

text https://leakyjar.intigriti.io/register

The attacker account used during exploitation was:

text noxzzdvnmbse9

Step 2: Inspect the vault

After logging in, I visited:

text https://leakyjar.intigriti.io/vault

The vault contained the user's recipe box and the sharing functionality.

The sharing feature allowed a user to enter another username and share the current recipe box with that user.

Step 3: Identify the missing CSRF protection

The sharing functionality submitted a POST request to /share with only the username parameter.

There was no CSRF token in the request.

This meant the request could be reproduced from another origin with a basic HTML form.

Step 4: Host the payload

I hosted the CSRF HTML payload on an attacker-controlled page.

The form was configured to submit to:

text https://leakyjar.intigriti.io/share

The hidden username field pointed to the attacker-controlled account:

text noxzzdvnmbse9

Step 5: Submit the payload to the Master Baker

The challenge included a submission feature where a URL could be sent to the Master Baker.

I submitted the hosted payload URL through:

text https://leakyjar.intigriti.io/submit

The application confirmed that the URL was accepted:

text Sent — the Master Baker will check it shortly.

Step 6: The Master Baker triggers the CSRF

When the Master Baker bot visited the submitted URL, the payload automatically submitted the hidden form.

The resulting request was equivalent to:

http POST /share HTTP/1.1 Host: leakyjar.intigriti.io Content-Type: application/x-www-form-urlencoded

username=noxzzdvnmbse9

Because the Master Baker was authenticated, the request was processed as the Master Baker.

This caused the Master Baker's recipe box to be shared with the attacker account.

Step 7: Access the shared recipe box

After the bot visited the payload, I returned to the attacker account and opened:

text https://leakyjar.intigriti.io/vault

The Shared with you section now contained:

text admin's recipe box View

Opening the shared recipe box revealed the Master Baker's private recipes.

Among them was the secret recipe containing the flag:

text Master Baker's Secret Recipe INTIGRITI{019ef404–1e44–7748-bdcf-ca7b12dbfee0}

Why This Worked

This worked because the server did not distinguish between:

1. A legitimate request submitted by the user from the LeakyJar interface.
2. A forged request submitted by an attacker-controlled cross-site form.

The browser did what browsers normally do: it submitted the form.

The server then accepted the request because the Master Baker's authenticated session was present.

The missing control was a CSRF token or equivalent request validation mechanism proving that the action was intentionally initiated from the legitimate application.

Why This Was One-click

The attack required only one victim interaction: the Master Baker bot visiting the submitted URL.

After the page loaded, the form submitted automatically.

The victim did not need to:

• Enter data. — Click an additional button. — Paste JavaScript. — Approve a browser prompt. — Interact with the LeakyJar UI directly.

That makes this a one-click CSRF chain in the context of the challenge.

Why This Was Not Self-XSS

This was not self-XSS because the victim was not tricked into executing JavaScript in their own browser console or modifying their own account manually.

The exploit was hosted externally and delivered through the intended challenge flow.

The actual vulnerability was server-side: the application accepted an authenticated state-changing request without verifying user intent.

Why MiTM Was Not Needed

No man-in-the-middle position was required.

The exploit did not rely on:

• Intercepting traffic. — Modifying packets. — Stealing cookies. — Proxying the victim. — Downgrading HTTPS.

It relied only on standard browser behavior and missing server-side CSRF protection.

Impact

The vulnerable action changed sharing permissions.

That is important because CSRF impact is often underestimated when people only think about profile changes or low-value actions. In this case, the CSRF affected authorization state.

By forcing the Master Baker to share its recipe box, the attacker gained access to private content that should not have been visible.

In the challenge, that private content included the flag:

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

In a real-world application, the same pattern could affect:

• File sharing. — Team invitations. — Permission delegation. — API key sharing. — Account linking. — Billing or organization access. — Private document exposure.

Any authenticated action that changes access control state should be treated as security-sensitive.

Recommended Fixes

1. Add anti-CSRF tokens 6

The /share endpoint should require a cryptographically secure anti-CSRF token.

The token should be:

• Random and unpredictable. — Bound to the user's session. — Included in the legitimate form. — Verified server-side before processing the request. — Rejected if missing, invalid, expired, or not associated with the current session.

A request like this should not be accepted:

http POST /share HTTP/1.1 Host: leakyjar.intigriti.io Content-Type: application/x-www-form-urlencoded

username=attacker

Expected behavior:

text 403 Forbidden Invalid or missing CSRF token

2. Validate Origin and Referer headers

Origin and Referer validation can provide useful defense-in-depth.

For sensitive state-changing requests, the server should reject requests where the origin does not match:

text https://leakyjar.intigriti.io

This should not replace CSRF tokens, but it can help block many cross-site form submission attacks.

3. Use safer SameSite cookie settings

Session cookies should use an appropriate SameSite policy where possible:

text SameSite=Lax

or:

text SameSite=Strict

If the application requires SameSite=None, then robust CSRF token validation becomes even more important.

4. Require explicit confirmation for sensitive sharing actions

Sharing a private resource should require clear user intent.

Useful protections include:

• Confirmation prompts. — Re-authentication for sensitive actions. — Notifications when a resource is shared. — A page listing active shares. — A way to revoke shared access.

5. Review other state-changing endpoints

The same class of vulnerability can exist anywhere authenticated state is changed.

Endpoints worth reviewing include:

text /share /vault/add /logout /account update routes /admin or internal state-changing routes

The general rule is simple:

If an endpoint changes server-side state, it should have CSRF protection.

Challenge Requirement Checklist

| Requirement | Result | Explanation | | — — — — — — — — — — — — — — — — — — — — | — — — — | — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -| | Vulnerability is on the challenge page | Passed | The issue was in LeakyJar's /share endpoint | | Not self-XSS | Passed | No console execution or victim self-exploitation required | | Not MiTM | Passed | No traffic interception or network manipulation required | | Works in Chrome | Passed | Uses standard HTML form submission behavior | | No more than one victim click | Passed | The Master Baker only had to visit the URL once | | Payload included | Passed | Auto-submitting HTML form shown above | | Flag recovered | Passed | INTIGRITI{019ef404–1e44–7748-bdcf-ca7b12dbfee0} |

Final Flag

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

Key Takeaway

This challenge was a strong reminder that CSRF is still relevant when the affected action changes authorization state.

The endpoint did not directly print the flag. Instead, the vulnerability allowed the attacker to manipulate who had access to the Master Baker's private recipe box. Once that access control state changed, the flag became available through normal application behavior.

That is what made the bug interesting.

The exploit was not about bypassing authentication directly. It was about abusing a missing intent check on an authenticated action.

For developers, the lesson is clear:

Any authenticated endpoint that changes sensitive state must verify that the request was intentionally initiated by the legitimate user.

For hunters, the lesson is equally clear:

Do not ignore CSRF on sharing, invitation, delegation, or permission-management features. Those flows often carry real impact because they control who can access private resources.