LoveLetterLocker-CTF Walkthrough

LoveLetterLocker presents itself as a cozy Valentine's-themed web application where users can safely store their private love letters. With a charming interface and promises of privacy ("For your eyes only?"), it invites users to trust their most intimate messages to its digital vault. However, as with many CTF challenges, things aren't always as secure as they appear. The application's claim of being a "safe" space for love letters becomes ironic once we discover its critical flaw.

The Vulnerability: Insecure Direct Object Reference (IDOR)

The core vulnerability lies in how the application handles access to stored letters. Instead of using unpredictable identifiers or implementing proper authorization checks, the application relies on simple sequential IDs that are easily guessable.

Exploitation Steps

STEP 1: Access the web app : [Y](http://10.48.129.64:5000/)``our Machine IP

Press enter or click to view image in full size

LoveLetter Locker landing page.

STEP 2: Register an Account

Press enter or click to view image in full size

User Dashboards.

STEP 3: Identify the Vulnerability

First Findings After logging in, notice the URL pattern for viewing letters:

http://TARGET_IP:5000/letters

http://TARGET_IP:5000/letters

We go back to the description of this challenge, "where we can safely write and store our Valentine's letters." So here are the clue for our findings.

Second Findings

The dashboards display the total letters in Cupid's archive: 2. This 2 letter already store on our account, but we never create any letter yet. Lets try create a new one.

Press enter or click to view image in full size

Now we got 3 letters, means the other 2 must be the flag. When we click "Open" on one of our letters, look at our browser's address bar. You'll see something like:

http://TARGET_IP:5000/letter/3

http://TARGET_IP:5000/letter/3

The pattern is /letter/[NUMBER] - this reveals that the application uses sequential numbers to identify letters. This is the key observation that leads to the IDOR vulnerability!

STEP 4: Exploit IDOR

Modify the URL to access letter #1:

http://TARGET_IP:5000/letter/1

http://TARGET_IP:5000/letter/1

STEP 5: Capture The Flag!

Press enter or click to view image in full size

The flag is revealed in Gonz0's love letter:

THM{1_c4n_r3ad_4ll_l3tters_w1th_th1s_1d0r}

THM{1_c4n_r3ad_4ll_l3tters_w1th_th1s_1d0r}

Congratulations, you have acquired the flag!

Why This Works

The application fails to verify that the authenticated user owns the requested letter. It trusts that users will only request their own letters — a classic example of "security through obscurity" rather than proper authorization.

Lessons Learned

• Never trust sequential IDs for access control — use UUIDs or similar unpredictable identifiers
• Always verify ownership — check that the authenticated user has permission to access the requested resource
• Implement proper access controls at the server level, not just in the UI

Conclusion for Our Walkthrough

LoveLetterLocker falls victim to a classic Insecure Direct Object Reference (IDOR) vulnerability. By simply incrementing the letter ID in the URL, an attacker can read any user's private letters, completely bypassing the application's intended privacy controls. This challenge serves as a reminder that security through obscurity is never enough — proper authorization checks are essential, even for seemingly low-risk features. Always verify that the authenticated user owns the resource they're requesting!