Granard
Granard is a small SaaS where teams collect customer feedback, let people vote, and share a public roadmap. You have an ordinary member account. The staff console holds a workspace service token that was never meant to leave the building. Find your way in.
The Scenario
Granard began as one developer's side project and quietly grew into a real product, with real customers and a small ops team that reads every piece of feedback that comes in.
You have a normal account, the same as everyone else. The staff who triage the board carry a key to the whole workspace. Take what they are holding.
Lab Intel
Synopsis
A feedback-board SaaS behind a Python edge proxy. The edge frames requests by Transfer-Encoding: chunked and reuses one keep-alive upstream connection across clients, while the app's HTTP front frames by Content-Length. That TE.CL disagreement lets a smuggled POST /feedback (its outer request sized to end exactly at the chunk-size line) sit mid-body on the pooled connection and swallow the next request that arrives on it. A staff bot polls the moderation queue through the edge every couple of seconds, so its authenticated request and session cookie are captured into the attacker's own stored feedback. Replaying that cookie reaches the staff console, which renders the workspace service token (the flag). The session is a plain replayable server-side token with no address binding, so the capture is a full account takeover.
Architecture
A medium three-service lab: a gateway (the edge, a Python asyncio proxy that frames by Transfer-Encoding: chunked and reuses a keep-alive pool of upstream connections across clients), an app service (a Content-Length-framing HTTP front plus gunicorn/Flask and SQLite, holding the board, the staff console and the flag), and a staff bot (a raw-socket client that makes one byte-identical authenticated GET /admin/queue through the edge every two seconds). The chain: recognise the TE.CL front/back framing disagreement, craft the capture (an outer request carrying BOTH a short Content-Length that the app honours to end the request at the first chunk-size line AND a chunked body that the edge honours, hiding a smuggled POST /feedback whose inner Content-Length is sized to swallow the bot's next request as its body), read the captured staff cookie back from your own feedback, then replay it to /admin. Because the edge returns the poisoned connection to its pool, the bot's request lands on it and its Cookie header is stored verbatim. Direct access to /admin with your own cookie returns 403 (you are not staff), and there is no /flag.txt, so the smuggle is the only path to the staff session. Distinct from the spread lab (CL.TE, self-contained, reach an unauth /admin): this is TE.CL, cross-user request capture, session hijacking and account takeover.
Who It's For
Players ready for their second request-smuggling desync, who want the high-impact real-world version: stealing another user's live session. You should be comfortable hand-crafting raw HTTP over a socket and reasoning about how a front proxy and a back-end app can disagree about where one request ends and the next begins.
Skills You'll Practice
- Recognising a TE.CL setup (front trusts Transfer-Encoding, back trusts Content-Length)
- Ending an outer request at the chunk-size line so the app parses a smuggled request next
- Sizing a smuggled Content-Length to capture another user's request, cookie and all
- Understanding cross-user keep-alive connection reuse as the capture vector
- Replaying a captured session cookie for account takeover
What You'll Gain
- A working model of TE.CL request smuggling and how it differs from CL.TE
- First-hand experience turning a desync into a live session theft, the way real ATO bug reports do
- Why blocking a path is not access control, and why sessions need address or device binding