P4wnda

picoCTF - Cookies

20 Apr 2025

Overview

This picoCTF challenge featured a web page that let users search for different types of cookies. At first glance, it seemed harmless — but under the hood, it revealed a classic Insecure Direct Object Reference (IDOR) vulnerability.

Using Burp Suite and cookie manipulation, I was able to brute-force a numeric identifier and extract the flag.


Step 1: Application Behavior

The page allows users to search for cookies by name using an input field. When a search is made, a request is sent with a cookie that looks like this:

Cookie: name=VALUE

Good Cookie

Certain cookies like snickerdoodle are recognized as valid but non-special:

That is a cookie! Not very special though…

Snickerdoodle Response

Others, such as bananacookie, return:

That doesn’t appear to be a valid cookie.

Bad Cookie

This suggests that cookie names are mapped to internal identifiers used for server-side validation.


Step 2: Inspecting the Request

Using Burp Suite, I noticed that the actual validation is done using a numeric value in the name cookie — not the string I typed in.

Example request:

GET /check HTTP/1.1
Host: mercury.picoctf.net:6418
Cookie: name=3

This hinted at an ID-based lookup — likely an internal ID corresponding to a cookie entry.


Step 3: Brute Forcing with Burp Intruder

To find the correct ID, I used Burp Intruder with the following settings:

  • Payload Position: name=§§
  • Payload Type: Numbers
  • Range: 0 to 25
  • Step: 1

After launching the attack, I observed the responses. All failed with the same rejection message — until request number 18.

Burp Intruder Results


Step 4: Success at ID 18

When the name=18 cookie was sent, the response included the flag.

This confirmed the vulnerability was an IDOR, where internal object references (in this case, cookie IDs) were not properly protected. Burp Suite Setup


Conclusion

This was a simple but effective example of an IDOR vulnerability in a web application. Even though user-facing input seemed harmless, internal validation logic exposed a numeric identifier that could be brute-forced.

Lessons:

  • Never trust client-side identifiers — especially when tied to authorization.
  • Always implement access controls and validation on the server side.
  • Rate limiting and session validation can help prevent brute-force attacks.

Flag: picoCTF{redacted_for_blog}