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.
Objective: Determine whether the application reflects, fetches, or redirects to the value supplied in the `website` parameter.
Context: With the modified URL in hand, use your browser and Burp Suite (Proxy → Intercept or HTTP History) to capture the full request/response cycle when the page loads.
Only reveal the ones you need. Claude tracks how many you used to calibrate the feedback.
Open Burp Suite, enable the proxy, and visit the modified invite URL. Check both the initial response and any subsequent requests the browser or server makes.
Look for three distinct behaviours: (1) the value appears in HTML/JS output (reflection), (2) the server issues an HTTP request to the supplied domain (SSRF), or (3) the browser is sent to the supplied domain (Open Redirect).
In Burp's HTTP History, filter for requests going OUT from the server to external hosts, or look for a 3xx Location header pointing to your supplied domain. Also check the rendered page source for the raw domain string.
Chat with a spoiler-safe tutor for this step. It uses only this lab spec and gives the smallest useful nudge first.
Tell the tutor what you tried, where you got stuck, or paste the response/error you are seeing.
Enjoying Hintru? Buy me a coffee ☕ ☕