SSRF - Server-Side Request Forgery

Wat is SSRF?

SSRF (Server-Side Request Forgery) is een kwetsbaarheid in webapplicaties. Een aanvaller laat de server HTTP-verzoeken sturen naar adressen die hij zelf bepaalt. De applicatie haalt bijvoorbeeld een afbeelding op via een door de gebruiker opgegeven URL, en die URL wordt onvoldoende gevalideerd. Het resultaat: de aanvaller bepaalt waar de server requests heen stuurt.

OWASP omschrijft het kernachtig: “SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL.” In MITRE-termen is dit CWE-918. Sinds 2021 staat SSRF als zelfstandige categorie A10 in de OWASP Top 10.

Die URL kan van alles aanroepen. Vaak een intern systeem dat de aanvaller normaal niet kan bereiken. Soms een cloud-metadata-endpoint dat credentials prijsgeeft. Soms een externe service die de aanvaller wil misbruiken vanaf uw IP-adres. De kern blijft dezelfde: de server bezoekt een URL die hij niet had mogen bezoeken.

Hoe werkt SSRF?

Stel, een applicatie biedt een functie waarbij een avatar-afbeelding via URL kan worden opgegeven:

# Normaal gebruik
curl -X POST https://app.example.com/api/profile/avatar \
  -H "Authorization: Bearer ..." \
  --data '{"image_url": "https://example.com/foto.jpg"}'

De server haalt die URL op en verwerkt het antwoord. Een aanvaller vervangt nu de waarde van image_url:

# SSRF: server haalt een door de aanvaller gekozen URL op
curl -X POST https://app.example.com/api/profile/avatar \
  -H "Authorization: Bearer ..." \
  --data '{"image_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'

De server stuurt vanaf zijn eigen positie een GET-request naar het AWS-metadata-endpoint, met de rechten en de netwerkpositie van die server. Het antwoord komt terug via de applicatie, vaak in een respons-body of foutmelding.

SSRF komt in twee hoofdvormen voor. Bij een reguliere SSRF ziet de aanvaller het antwoord van het verzoek rechtstreeks terug. Bij een blinde SSRF is dat antwoord niet zichtbaar; de aanvaller weet alleen dát het verzoek is uitgevoerd. Een blinde SSRF wordt bevestigd via een out-of-band callback. De aanvaller laat de server een verzoek doen naar een eigen logging-domein, bijvoorbeeld via Burp Collaborator. Komt die request binnen, dan is de kwetsbaarheid bewezen.

Wat kan een aanvaller met SSRF bereiken?

De impact varieert sterk per omgeving:

• Toegang tot interne systemen. Admin-panelen, monitoring-dashboards en ongeauthenticeerde Redis- of Elasticsearch-instances zijn vanaf het internet onbereikbaar. Via de kwetsbare applicatie worden ze opeens benaderbaar.
• Cloud-credentials buitmaken. AWS, Azure en Google Cloud bieden een instance-metadata-service (AWS op 169.254.169.254, GCP op metadata.google.internal) die alleen vanaf de VM zelf bereikbaar is. Een werkende SSRF in een cloud-applicatie kan via dit endpoint geldige IAM-credentials, access tokens of service-account keys opleveren. De Capital One-breach in 2019 (ruim 100 miljoen klantgegevens) verliep via dit exacte patroon.
• Protocol-misbruik. Naast http:// accepteren sommige HTTP-libraries ook file:// (bestanden lezen op de server), gopher:// (rauwe TCP-payloads versturen, klassieke Redis-RCE-vector) of dict:// (interactie met dict-servers). Deze schemes geven een breder aanvalsoppervlak dan alleen HTTP.
• Misbruik van het IP-adres van uw server. Een aanvaller laat de applicatie grote aantallen requests doen naar externe diensten (Google, GitHub, e-mailproviders). Het IP van uw server komt daardoor op een blacklist, waarna legitieme functies stuk gaan: updates lopen vast, dependency-installs falen, transactionele e-mails worden geweigerd. SSRF hoeft geen data te lekken om bedrijfsverstorend te zijn.

SSRF in een pentest

Tijdens een webapplicatie pentest lopen wij systematisch elke plek langs waar een URL als invoer wordt geaccepteerd. De zichtbare kandidaten zijn webhook-configuratie en avatar-uploads. Er zijn ook minder voor de hand liggende plekken: import-functies vanuit externe URLs, OAuth-redirect-callbacks, PDF- of HTML-export, RSS- en feed-readers, en backend-integraties met derden.

Per kandidaat proberen we een vaste reeks payloads: interne IP-ranges, localhost, cloud-metadata endpoints, een eigen out-of-band server om blinde SSRF te bevestigen, en niet-HTTP schemes om filters te omzeilen. Reageert de server met content, een foutmelding of timing-verschillen die op een uitgevoerd verzoek wijzen? Dan demonstreren we welke interne systemen en gegevens via die weg bereikbaar zijn. Een werkende keten van SSRF naar cloud-credentials laten we werkend zien, niet enkel theoretisch.

Hoe voorkomt u SSRF?

OWASP’s eerste adviespunt is duidelijk: gebruik een positieve allowlist, geen denylist. Allowlist betekent dat de applicatie een vaste set toegestane URL-bestemmingen kent en al het andere weigert.

• Sta alleen URLs toe uit een vooraf gedefinieerde allowlist van hostnames die uw applicatie echt nodig heeft. Een blocklist op IP-ranges schiet bijna altijd tekort. Aanvallers omzeilen die met DNS-rebinding, IP-encoding-varianten (decimaal, octaal, hex) of redirect-chains.
• Resolveer de hostname zelf in uw applicatiecode. Weiger het verzoek als de DNS-resolutie een private IP-range oplevert (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16). Validatie hoort op het IP-adres na DNS-resolutie, niet op de hostname-string.
• Beperk URL-schemes tot https:// (en eventueel http:// als dat strikt nodig is). Sta file://, gopher:// en dict:// niet toe; deze worden nooit gebruikt voor legitieme web-fetches.
• Schakel HTTP-redirects uit, of volg ze pas na hervalidatie met dezelfde regels. Een groot deel van de SSRF-vondsten zit juist in de redirect-follow-logica: de oorspronkelijke URL is legitiem, de redirect wijst naar localhost.
• Draait de applicatie in AWS? Schakel IMDSv2 verplicht in. De metadata-service vraagt dan eerst om een sessietoken via een PUT-verzoek voordat hij credentials teruggeeft. De meeste SSRF-payloads zijn GET-verzoeken en komen daar niet doorheen.

Op netwerkniveau helpt egress-filtering: laat applicatieservers alleen die externe en interne diensten bereiken die ze daadwerkelijk nodig hebben. Het loggen van zowel toegestane als geblokkeerde uitgaande verbindingen maakt SSRF-pogingen detecteerbaar in plaats van onzichtbaar.