IntroToBurp picoCTF 2024 Solution

Description

1. Step 1

   Register with dummy data

   Observation

   I noticed the challenge landing page presents a registration form before exposing any other functionality, which suggested I needed to create a throwaway account first so the server would issue a session and advance me to the next attack surface.

   Fill out the first form with any values and submit. This leads to the OTP verification page.

   Learn more

   Burp Suite is an industry-standard web application security testing platform made by PortSwigger. Its core feature is an intercepting proxy that sits between your browser and the target server, letting you read, pause, and modify every HTTP/HTTPS request and response in real time.

   When you use Burp's embedded Chromium browser, all traffic is automatically routed through the proxy without any certificate trust issues. This is the fastest way to get started, since configuring an external browser to trust Burp's self-signed CA can take extra steps.

   In real-world penetration testing, the registration step is always done first so you have a valid session to work with. Even throwaway credentials give the server enough state to present the next attack surface - in this case, the OTP form.

2. Step 2

   Intercept the OTP submission and mangle the field name

   Observation

   I noticed the OTP form performs client-side validation in the browser before submitting, which suggested a Burp Suite intercept could catch the POST body mid-flight and let me rename the otp parameter so the server-side lookup never finds it and skips the check.

   Turn Intercept ON in Burp's Proxy tab, enter any value in the OTP field, and submit. In the captured request body you will see otp=999 (or whatever you typed). Change the field name from otp to something like otgp so the parameter is otgp=999. The server-side code never finds the otp field, skips the check, and grants access.

   bash

   (Intercepted request body) ...&otgp=999&...

   Copied!

   What didn't work first

   Tried: Delete the otp field's value entirely, sending otp= with an empty string, instead of renaming the field.

   Many servers treat an empty string as a present-but-invalid OTP and return an error like 'Invalid OTP'. The bypass only works when the field name itself is absent so the server-side lookup returns null and the check is never reached. Renaming the field to otgp ensures the otp key does not appear in the POST body at all.

   Tried: Modify the request in the browser's DevTools Network tab using 'Edit and Resend' instead of setting up Burp.

   Browser DevTools block resending requests that have already been dispatched, and the 'Edit and Resend' feature in most browsers does not support modifying the POST body of a form submission mid-flight. Burp's intercepting proxy sits at the TCP layer and can pause and alter the raw byte stream before it leaves the machine, which is why a true MITM proxy is required here.

   Learn more

   Mangling the field name is a different bypass from clearing the value. Here the server-side OTP check looks up a specific parameter name (otp). When you rename it to otgp, the lookup returns null or an empty string, and if the server code does not enforce that the field was present with a non-null value, it skips the check entirely and grants access.

   This is why proxy interception bypasses any client-side validation: the browser's JavaScript runs its checks before submission, but Burp captures the request after JS has signed off, sitting between your browser and the server. You can mutate the body freely; the server only sees your modified request.

   This is called an OTP bypass and is a well-documented class of authentication vulnerability. Related bugs include accepting any OTP value, not expiring OTPs after use, or not rate-limiting brute-force attempts.

   • Intercept mode in Burp pauses each request so you can edit the raw body or headers before forwarding.
   • The otp= parameter appears in the POST body in application/x-www-form-urlencoded format.
   • Renaming the field tests whether the server validates that the specific named field was provided at all.
3. Step 3

   Forward the tampered request

   Observation

   I noticed the intercepted request body was already modified with the renamed field, which suggested forwarding it immediately would reach the server with the otp key absent and trigger the flag response without any further edits.

   Forward the modified request to the server. Because the otp field name is missing, the server skips the OTP check and the response contains the flag immediately.

   Learn more

   Forwarding in Burp sends the (now modified) HTTP request to the actual server and lets you see the real response. When authentication logic is missing an empty-value check, the server returns whatever is normally shown after successful verification - in this challenge, the flag.

   This attack demonstrates why server-side validation is essential. Client-side checks (JavaScript that prevents form submission with an empty field) are trivially bypassed by any proxy tool. The server must independently verify that the OTP field is present, non-empty, and matches the expected value.

   In production systems, robust OTP implementations use time-based algorithms (TOTP, RFC 6238) and enforce server-side expiration and attempt limits, making this type of bypass impossible.

Flag

Tampering with the OTP parameter yields the flag immediately.