Recon with the Wayback Machine surfaced an appointment-booking platform that carried session tokens in GET parameters and leaked personal data in archived URLs. From there it turned manual: a space-free XSS in the phone field a previous hunter had missed, and a stored XSS through a file-upload URL reflected unsanitised into the admin panel.

A journey from automated discovery to manual exploitation, in an appointment-booking system.

1. Identifying initial targets

I built a list of candidate targets and fed each one's archived history, pulled from the Wayback Machine, through waybackurls:

cat targets | waybackurls > crawler.txt

2. Automating the hunt

Then I mined the crawl for common patterns: base64-encoded mails, emails sitting in parameters, and so on. You can lean on gf, or just use a regex:

cat crawler.txt | grep -E '\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b'

A sample of what came back: archived URLs carrying personal data right in the query string.

→ target cat crawler.txt | grep -E '...' | tail -n 1
http://<redacted>.com/...?...&first_name=...&last_name=...&phone=...&email=...@yahoo.com
→ target

3. Stumbling on a PII leak

One target stood out: it leaked PII through GET parameters, and one URL pattern kept repeating, a SessionID-style value carried in the query string.

→ target cat target.txt | grep PHPSESSID | tail -n 1
https://<redacted>/...?...&PHPSESSID=...qkf8shjv
→ target

A session token living in a GET parameter is a problem on its own: it ends up in browser history, server logs, referrer headers, and, here, the Wayback Machine.

4. Understanding the architecture

The target was an appointment-booking platform. Guests schedule appointments with the site's users, and instead of cookie-based sessions it used GET parameters as session tokens so users could manage their appointments straight from a link.

APPOINTMENT BOOKING · SESSIONS CARRIED IN GET PARAMETERS adminmanages appointments admin panelappointment manager booking websitePHP back end guestquick visit · no account books ?…&PHPSESSID=… → session token rides in the URL ✕ leaks to history, logs, referrers, Wayback
Fig. 01 - the architecture. Guests book appointments without an account; the site tracks sessions with a PHPSESSID in the query string instead of a cookie, so the token leaks into archived URLs.

5. Unmasking the vulnerabilities

Going manual, I stood up a manager-side account to interact with the application and found it was built in PHP, fertile ground for SQL injection and XSS. The guest-facing fields were name, phone, and notes.

  • XSS in the notes field was already reported (it came back as a duplicate).
  • XSS in the phone field, with no spaces, was accepted. The previous hunter's filter clearly keyed on spaces:
<img/src='1'/onerror=alert`1`>

Using slashes instead of spaces slipped straight past the filter.

6. XSS through the file-upload flow

Enabling more guest fields surfaced a file upload. It used a third-party cloud-storage service: the guest uploads a file, the service returns the file URL, and that URL is stored in a request parameter and later shown on the admin side.

The URL was reflected into an href on the admin panel unsanitised, so a crafted "URL" became script:

javascript:alert()
"><img src=x onerror=alert()>

This was more severe than the phone-field XSS: it needed no elevated privileges, so any guest could fire it in the admin's session.

FILE UPLOAD · ATTACKER-CONTROLLED URL REFLECTED TO ADMIN guestuploads a file cloud storagethird-party service 1 · upload file 2 · returns file URL, saved in a post parameter guestcontrols the URL serverstores URL, no sanitising admin panelURL placed in href 3 · send URL 4 · reflect "><img src=x onerror=alert()> ✕ attacker-set URL rendered in href, unsanitised → XSS in admin session
Fig. 02 - the upload data flow. The guest controls the file URL the cloud service returns; the server stores it and the admin panel renders it inside an href without sanitising, so a crafted URL executes as script in the admin's session.

7. Takeaways

  • Recon pays compounding interest. Wayback plus waybackurls plus a single regex turned archived noise into both a PII leak and an entry point.
  • Session tokens belong in cookies, not URLs. A token in a GET parameter leaks everywhere by design.
  • Other people's filters have blind spots. A space-free payload beat a space-based filter, and a field flagged "duplicate" right next door was still exploitable.
  • Reflected third-party URLs are sinks. Render an attacker-influenced URL in an href without sanitising and you have XSS.

Thanks for reading.