Server-side request forgery (SSRF)

Server-side request forgery, kortweg SSRF, is een van de sluipendste webkwetsbaarheden: de aanvaller stuurt niet uw browser aan, maar uw eigen server. In deze uitleg leest u wat SSRF is, hoe zo’n aanval in de praktijk verloopt, wat een aanvaller ermee kan bereiken en hoe u uw applicatie ertegen dichttimmert.

Wat is server-side request forgery?

Server-side request forgery (SSRF) is een kwetsbaarheid waarbij een aanvaller uw server zover krijgt dat die namens hem verbindingen opzet naar een adres dat de aanvaller kiest. De applicatie denkt dat ze een legitiem verzoek doet, maar fungeert in werkelijkheid als doorgeefluik naar plekken die de aanvaller zelf nooit had mogen bereiken.

Vergelijk het met een receptionist die elk telefoonnummer belt dat een bezoeker op een briefje schrijft. De bezoeker staat buiten en komt het gebouw niet in, maar de receptionist zit binnen, en kan dus ook interne toestellen bellen. Vraagt de bezoeker om “toestel 1234, de kluiskamer”, dan belt de receptionist dat gedwee, want het staat immers op het briefje. SSRF misbruikt precies die vertrouwenspositie van de server binnen het netwerk.

Hoe werkt een SSRF-aanval?

SSRF ontstaat overal waar een applicatie een URL of adres uit gebruikersinvoer haalt en die vervolgens zelf ophaalt: een webhook, een “importeer via URL”-functie, een link-preview, een PDF-generator of een afbeeldingsproxy. Zolang die invoer niet wordt gecontroleerd, bepaalt de gebruiker naar welk adres de server verbinding maakt.

Kwetsbaar:

// Afbeeldingsproxy die klakkeloos elk opgegeven adres ophaalt
app.get('/fetch', async (req, res) => {
  const url = req.query.url;
  const response = await fetch(url);
  const body = await response.text();
  res.send(body);
});

Deze proxy haalt elk adres op dat in de queryparameter staat. Vraagt een aanvaller /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ op, dan bevraagt de server het metadata-endpoint van de cloudprovider en stuurt de tijdelijke toegangssleutels terug in de respons. Een adres als http://localhost:6379 opent net zo makkelijk de interne Redis-database, en file:///etc/passwd leest desgewenst lokale bestanden.

Veilig:

import dns from 'node:dns/promises';

const ALLOWED_HOSTS = new Set(['images.example.com', 'cdn.example.com']);

function isPrivate(ip) {
  return /^(10\.|127\.|169\.254\.|192\.168\.|::1|fc00:|fe80:)/.test(ip)
    || /^172\.(1[6-9]|2\d|3[01])\./.test(ip);
}

app.get('/fetch', async (req, res) => {
  let target;
  try { target = new URL(req.query.url); }
  catch { return res.status(400).send('Ongeldige URL'); }

  if (target.protocol !== 'https:') return res.status(400).send('Alleen https');
  if (!ALLOWED_HOSTS.has(target.hostname)) return res.status(403).send('Host niet toegestaan');

  const { address } = await dns.lookup(target.hostname);
  if (isPrivate(address)) return res.status(403).send('Geblokkeerd');

  const response = await fetch(target, { redirect: 'error' });
  res.send(await response.text());
});

De veilige variant knijpt drie kranen tegelijk dicht. Eerst wordt de invoer als echte URL geparset en beperkt tot https. Daarna moet de hostnaam voorkomen op een expliciete allowlist: alleen wat u vooraf goedkeurt, mag erdoor. Ten slotte wordt de hostnaam omgezet naar een IP-adres en gecontroleerd tegen private en link-local reeksen, zodat een goedgekeurde naam die stiekem naar 127.0.0.1 of 169.254.169.254 wijst alsnog sneuvelt. Door redirects te verbieden voorkomt u dat een externe server u in tweede instantie tóch naar binnen stuurt.

Wat is de impact van SSRF?

De ernst van SSRF loopt sterk uiteen, en dat verklaart de spanwijdte van medium tot kritiek. In een afgeschermde omgeving zonder interessante interne diensten blijft het misschien bij het aftasten van poorten. Maar in een typische cloudopstelling is de buit groot: het metadata-endpoint (169.254.169.254) geeft tijdelijke inloggegevens vrij, en met die sleutels kan een aanvaller vaak de hele cloudomgeving overnemen.

Technisch gezien opent SSRF de deur naar alles wat de server intern kan bereiken: adminpanelen zonder externe toegang, interne API’s, databases, de Kubernetes-API of een berichtenwachtrij. De aanvaller kan het interne netwerk in kaart brengen, gevoelige data buitmaken en soms een SSRF ombuigen tot volledige remote code execution. Voor het bedrijf betekent dat datalekken, misbruik van clouddiensten op uw rekening en een aanvaller die zich vanuit één zwak endpoint lateraal door de infrastructuur beweegt. Een bekend voorbeeld is het datalek bij Capital One in 2019, waarbij een SSRF-aanval de AWS-metadata bereikte en gegevens van ruim honderd miljoen klanten blootlegde.

Hoe spoor je SSRF op?

Bij een handmatige test voert een pentester in elk veld dat een URL of host lijkt te accepteren een adres in dat naar een server onder eigen beheer wijst, en let vervolgens op de callback. Komt er een DNS- of HTTP-verzoek binnen, dan haalt de applicatie het adres dus daadwerkelijk op. Ook zonder zichtbare respons, de zogeheten blinde SSRF, verraadt zo’n uitgaand verzoek de kwetsbaarheid. Daarnaast worden metadata-endpoints, alternatieve IP-notaties en redirects beproefd om filters te omzeilen. Geautomatiseerde scanners markeren verdachte URL-parameters, maar missen vaak juist de blinde varianten. AssistSec neemt SSRF standaard mee in een penetratietest en controleert nadrukkelijk die blinde gevallen.

Hoe voorkom je SSRF?

• Werk met een allowlist van toegestane hosts, domeinen en protocollen; weiger al het andere.
• Sta alleen http en https toe en blokkeer schema’s als file, gopher, ftp en dict.
• Zet de hostnaam om naar een IP-adres en blokkeer private, loopback en link-local reeksen, inclusief IPv6 en 169.254.169.254.
• Verbied redirects of valideer elke redirect opnieuw tegen dezelfde regels.
• Draai de fetch-functionaliteit met minimale rechten in een apart, afgeschermd netwerksegment.
• Schakel cloud-metadata uit of dwing IMDSv2 met token af, zodat één simpel GET-verzoek geen sleutels prijsgeeft.
• Geef de opgehaalde inhoud niet ongefilterd terug en monitor uw uitgaande verkeer op onverwachte bestemmingen.