SnapProof webhook SSRF
A document-notarization service. The completion webhook URL is fetched server-side with no restriction.
0 solves
The server fetches a URL on your behalf, and nothing stops that URL from pointing somewhere it shouldn't.
Server-side request forgery (SSRF) happens when a server fetches a URL supplied, directly or indirectly, by a user, and nothing stops that URL from pointing at a destination the server was never meant to reach.
$response = file_get_contents($_POST['webhook_url']);
Nothing here stops that URL from being http://169.254.169.254/latest/meta-data/
(a cloud instance's metadata endpoint) or http://127.0.0.1:9200/ (an
internal service with no auth of its own, because it was never meant to be
reachable from outside).
SSRF is how a routine webhook or "preview this URL" feature turns into cloud credential theft (metadata endpoints hand out temporary cloud credentials to anything that asks from inside the network) or a foothold into internal-only services with weak or no authentication.
$host = parse_url($url, PHP_URL_HOST); if (!in_array($host, ALLOWED_HOSTS, true)) { throw new InvalidArgumentException('Host not allowed.'); } // Re-check the resolved host again after following any redirect, // not only the URL the caller originally submitted.
Allow-list destination hosts, resolve and check the actual IP against private and link-local ranges, and re-validate after every redirect, not just the URL as first submitted.
A document-notarization service. The completion webhook URL is fetched server-side with no restriction.
0 solves
A solar-fleet monitoring dashboard. A host allow-list is checked once, before any redirect is followed.
0 solves