Redirect Run
Quikpay's receipt shortlinks pass through a redirect step. Sometimes the answer is in the message you skipped right past.
The Scenario
Quikpay generates short, shareable receipt URLs for merchants. Visiting one bounces you to a friendly "thanks for your purchase" landing page. The redirect that gets you there isn't as silent as it looks — there's something the engineering team forgot to strip out of the intermediate response.
Challenge Intel
Synopsis
An introduction to seeing every step of an HTTP exchange, not just the final destination.
What It Is
Quikpay's receipt shortlink endpoint `/r/<token>` returns an HTTP 302 with `Location: /receipt`. The intermediate response body contains the flag inside a developer-debug `<pre>` block that should never have been left in. Browsers and `curl` (default) follow the redirect and only show the final landing page — the flag is gone. Players solve by inspecting the 302 response itself: `curl -i --max-redirs 0 /r/<token>` or Burp HTTP history.
Who It's For
Brand-new web hackers — anyone who hasn't yet wrangled a redirect chain manually.
Skills You'll Practice
- Reading intermediate responses in a redirect chain
- Using `curl --max-redirs 0` and `curl -i`
- Burp Suite HTTP history and the 'Follow redirects' control
- Recognising that browsers hide the redirect step from the rendered page
What You'll Gain
- First confident inspection of a 302 response body
- An instinct that the final page isn't the only response a request produced
- Vocabulary for talking about redirect chains and debugging them
- Comfort flipping client behaviour to see what the server actually says