Wanneer een applicatie een URL namens een gebruiker opvraagt, kan die server onbedoeld toegang geven tot interne systemen of cloudvoorzieningen. Lees hoe SSRF ontstaat en welke controles op invoer, DNS, redirects en netwerkverkeer het risico beperken.
Hoe SSRF ontstaat wanneer een server URL’s opvraagt
Server-Side Request Forgery (SSRF) ontstaat wanneer een aanvaller een applicatie een verzoek laat doen naar een adres dat hij zelf kiest. De applicatie voert dat verzoek uit met de netwerktoegang en rechten van de server, niet met die van de gebruiker. Een functie voor het ophalen van een afbeelding, het importeren van een document of het controleren van een webhook kan daardoor een ingang vormen naar bestemmingen die vanaf het internet niet bereikbaar zijn.
Het kernprobleem is een vertrouwensgrens: invoer die als gewone URL wordt behandeld, bepaalt in werkelijkheid waar de server verbinding mee maakt. Een externe URL kan bijvoorbeeld worden vervangen door een intern adres, een loopback-adres of een hostnaam die naar een interne bestemming verwijst. De server kan vervolgens een beheerinterface, interne API of cloudmetadata-endpoint benaderen. Zelfs als de inhoud niet rechtstreeks aan de aanvaller wordt getoond, kunnen verschillen in responstijd, statuscode of foutmelding informatie lekken.
SSRF is niet beperkt tot eenvoudige HTTP-clients. Ook bibliotheken voor afbeeldingen, PDF-conversie, XML-verwerking en documentimport kunnen URL’s ophalen. Risico ontstaat vooral wanneer de applicatie de bestemming niet beperkt, of wanneer de controle en het daadwerkelijke verzoek verschillende interpretaties van dezelfde invoer gebruiken.
Risicovolle URL-invoer herkennen in applicatiefuncties
Begin bij functies waarin een gebruiker een adres kan invoeren of indirect kan aanleveren. Denk aan een veld voor een afbeeldings-URL, een importfunctie voor feeds, een preview van een webpagina, een avatar die vanaf een externe host wordt geladen en integraties die callbackadressen accepteren. URL’s kunnen ook verstopt zitten in bestanden, API-payloads of metadata. Een functie hoeft niet expliciet een URL-veld te tonen om uiteindelijk een serververzoek op basis van gebruikersinvoer te doen.
Inventariseer per functie welke component de URL verwerkt, welke bibliotheek het verzoek uitvoert, welke protocollen zijn toegestaan en wat er met de response gebeurt. Een URL die alleen wordt gebruikt om een titel op te halen, kan toch een volledige HTTP-response downloaden of redirects volgen. Een preview-service kan bovendien HTML verwerken, waarna een tweede component aanvullende bestanden ophaalt. Elke stap introduceert een nieuw verzoek en mogelijk een nieuwe bestemming.
Maak onderscheid tussen adressen die een gebruiker invoert en adressen die de applicatie zelf samenstelt. Een door de applicatie samengestelde URL is niet automatisch veilig als onderdelen daarvan, zoals host, pad of queryparameters, door gebruikers worden beïnvloed. Leg ook vast of verzoeken synchroon worden uitgevoerd in een webproces of via een achtergrondtaak. Dat verschil bepaalt welke netwerkrechten, logs en beperkingen van toepassing zijn.
URL-validatie met allowlists en consistente parsing
Een betrouwbare URL-controle begint met een vaste parser die dezelfde interpretatie gebruikt als de HTTP-client. Controleer expliciet het schema, de host, de poort en eventuele gebruikersinformatie in de URL. In veel toepassingen volstaat een beperkte allowlist van protocollen en hosts, bijvoorbeeld HTTPS naar vooraf goedgekeurde integratiedomeinen. Een allowlist is doorgaans beter te beoordelen dan een blacklist met bekende interne adressen: een blacklist moet iedere alternatieve schrijfwijze en toekomstige netwerkroute blijven afvangen.
Normaliseer de invoer voordat beleidsregels worden toegepast, maar vertrouw niet op een eigen reeks tekstvervangingen. Verschillende parsers kunnen afwijkend omgaan met hoofdletters, percent-encoding, IPv6-notatie, een punt achter een hostnaam of speciale tekens rond het hostgedeelte. Als de validatielaag één host ziet en de netwerkclient een andere, is de controle betekenisloos. Weiger ongeldige of dubbelzinnige URL’s in plaats van ze stilzwijgend te corrigeren.
Een allowlist moet passen bij de functie. Als een integratie alleen bestanden van een specifiek domein hoeft te halen, beperk dan ook subdomeinen en poorten waar dat kan. Een regel die elk subdomein accepteert, kan ruimer zijn dan bedoeld wanneer een derde partij of gebruiker subdomeinen kan beheren. Valideer daarnaast pad- en queryparameters wanneer die toegang tot gevoelige functies kunnen geven. URL-validatie is een beleidscontrole, geen vervanging voor netwerkisolatie.
DNS-resolutie en DNS-rebinding beheersen
Een hostnaam kan naar verschillende IP-adressen verwijzen, waaronder adressen in interne, loopback- of link-local bereiken. Daarom is het niet voldoende om alleen te controleren of de tekst van een URL een intern IP-adres bevat. De applicatie moet de hostnaam laten resolveren en de verkregen adressen toetsen aan beleid. Daarbij horen IPv4 en IPv6, inclusief lokale bereiken en bijzondere adressen die niet voor publieke bestemmingen bedoeld zijn.
Een lastiger geval is DNS-rebinding. Een aanvaller kan DNS-antwoorden zo laten wisselen dat de validatie een publiek adres ziet, terwijl de HTTP-client bij het verbinden een intern adres krijgt. Dit kan gebeuren wanneer de applicatie de naam apart valideert en de client later opnieuw resolveert. Een robuustere aanpak koppelt de gecontroleerde resolutie aan de daadwerkelijke verbinding, of gebruikt een netwerklaag die uitgaande verbindingen naar verboden bereiken blokkeert. Welke aanpak haalbaar is, hangt af van de gebruikte HTTP-client en infrastructuur.
Controleer alle IP-adressen die een resolver teruggeeft; accepteer niet automatisch de eerste. Denk ook aan caching: een positieve cache kan een oud antwoord vasthouden, terwijl korte TTL’s frequente wijzigingen toelaten. Log de oorspronkelijke hostnaam én het uiteindelijke bestemmingsadres, zodat afwijkingen onderzoekbaar zijn. Bij gebruik van een proxy moet duidelijk zijn of de applicatie of de proxy DNS-resolutie uitvoert, want de validatie moet aansluiten op de component die daadwerkelijk de verbinding maakt.
Redirects en protocollen beperken bij externe verzoeken
Een veilige eerste bestemming garandeert niet dat het uiteindelijke verzoek veilig blijft. Een publieke URL kan een redirect teruggeven naar een intern adres, waarna de HTTP-client die automatisch volgt. Schakel automatisch volgen uit wanneer de functie het niet nodig heeft. Als redirects functioneel vereist zijn, behandel elke nieuwe locatie als een nieuwe bestemming: parseer de URL opnieuw, pas dezelfde allowlist toe, resolve de host opnieuw en beperk het aantal redirectstappen.
Controleer ook of een redirect van HTTPS naar HTTP is toegestaan. Zo’n overgang kan vertrouwelijkheid en integriteitsbescherming verminderen, terwijl een redirect naar een andere host de oorspronkelijke domeincontrole omzeilt. Sommige clients sturen headers, cookies of authenticatiegegevens mee naar vervolgverzoeken. Zorg dat geheimen niet onbedoeld naar een andere host worden doorgestuurd en dat redirects geen eerder geweigerde bestemming alsnog bereikbaar maken.
Beperk het schema tot wat de toepassing nodig heeft, meestal HTTP of HTTPS, en laat clients geen onverwachte protocollen verwerken. Sommige bibliotheken ondersteunen naast HTTP bijvoorbeeld bestandstoegang of andere transports. Dat kan lokale bestanden of niet-HTTP-diensten bereikbaar maken wanneer de gebruiker het schema kan beïnvloeden. Controleer daarom niet alleen de URL-validatie, maar ook de configuratie van de gebruikte client, eventuele proxy-instellingen en de mogelijkheden van onderliggende libraries. Upgrades kunnen standaardgedrag rond redirects of protocollen wijzigen; leg dat gedrag vast in tests.
Uitgaand netwerkverkeer beperken met egressregels
Applicatiecontroles kunnen een fout bevatten of worden omzeild door een onverwachte parser- of DNS-situatie. Netwerkbeperkingen vormen daarom een onafhankelijke verdedigingslaag. Laat een proces dat externe URL’s ophaalt alleen verbinding maken met de bestemmingen die het voor zijn functie nodig heeft. Blokkeer waar mogelijk verbindingen naar interne subnetten, loopback, link-local adressen en andere niet-publieke bereiken. Een firewallregel die uitsluitend op een applicatieveld vertrouwt, biedt weinig bescherming als het proces zelf onbeperkt netwerktoegang heeft.
De praktische inrichting verschilt per omgeving. In een cloudnetwerk kunnen security groups, netwerkbeleid of egress-proxy’s uitgaand verkeer begrenzen. In containerplatforms kunnen netwerkpolicies per workload worden toegepast. Een proxy kan bestemmingen centraal toetsen en logging uniformeren, maar alleen als applicaties niet rechtstreeks om de proxy heen kunnen verbinden. Houd rekening met DNS-verkeer, IPv6 en interne routes; een regel die uitsluitend IPv4 afdekt, kan een alternatieve route openlaten.
Isolatie heeft functionele gevolgen. Een service die documenten ophaalt, kan legitiem meerdere externe domeinen nodig hebben, terwijl een brede internettoegang het effect van een SSRF vergroot. Scheid zulke taken daarom waar passend van de hoofdapplicatie en geef ze alleen de benodigde netwerktoegang. Test ook foutscenario’s: bij een onbereikbare proxy of mislukte beleidscontrole mag de client niet stil terugvallen op een onbeperkte directe verbinding.
Cloudmetadata en interne diensten als SSRF-doelwit
Een SSRF-aanval is vooral ernstig wanneer de server interne diensten kan bereiken die vertrouwen op netwerkpositie in plaats van sterke authenticatie. Cloudmetadata-endpoints kunnen informatie over de omgeving of tijdelijke toegangsgegevens beschikbaar maken. Interne beheertools, service-discovery, databases en API’s kunnen eveneens bereikbaar zijn vanaf de applicatieserver, ook als ze niet publiek zijn gepubliceerd. De impact hangt af van de netwerkarchitectuur en de rechten die het getroffen proces heeft.
Beperk daarom niet alleen de URL-invoer, maar verklein ook de waarde van een succesvolle verbinding. Gebruik waar beschikbaar metadata-voorzieningen met aanvullende beschermingsmechanismen en voorkom dat applicatieprocessen zonder noodzaak bij metadata-endpoints kunnen. Geef workloads afzonderlijke identiteiten en minimale rechten, zodat verkregen credentials geen brede toegang bieden tot andere diensten. Interne API’s moeten authenticatie en autorisatie afdwingen; een verzoek vanaf een intern IP-adres mag niet automatisch als vertrouwd gelden.
Een response hoeft niet altijd volledig zichtbaar te zijn om misbruik mogelijk te maken. De applicatie kan gegevens opslaan, doorsturen, verwerken of alleen een foutmelding tonen. Ook een blind SSRF kan worden gebruikt om te testen welke interne hosts reageren of om een dienst indirect te activeren. Beperk daarom zowel de bereikbaarheid als de hoeveelheid response-informatie die aan gebruikers wordt teruggegeven. Foutmeldingen kunnen operationele details bevatten, maar horen geen interne adressen, headers of gevoelige response-inhoud prijs te geven.
Externe integraties ontwerpen zonder open URL-proxy
Integraties voor webhooks, previews en imports hebben verschillende vertrouwensmodellen en verdienen afzonderlijke controles. Bij een webhook registreert een gebruiker doorgaans een bestemming waar de applicatie later gegevens naartoe stuurt; bij een import haalt de applicatie juist inhoud op. Die richtingen brengen andere risico’s mee. Een generieke functie die willekeurige URL’s accepteert en volledige responses teruggeeft, gedraagt zich al snel als een open proxy. Dat kan interne netwerken blootstellen en misbruik van de server als tussenstation mogelijk maken.
Beperk functies tot hun werkelijke behoefte. Voor een preview kan een aparte fetch-service alleen HTML ophalen, zonder cookies of applicatiecredentials, met een maximale responsegrootte en beperkte verwerking. Voor een import kan de applicatie bestandstypen, contentlengte en toegestane hosts afbakenen. Een webhook die gegevens verstuurt, vraagt om controles op uitgaande bestemmingen, redirectgedrag en het lekken van headers. Behandel ingevoerde webhookadressen niet als blijvend veilig: DNS en de bestemming kunnen na registratie veranderen.
Voorkom dat een achtergrondtaak een eerder gevalideerde URL zonder hercontrole uitvoert. Tussen registratie en uitvoering kan DNS wijzigen, kan een redirect zijn toegevoegd of kan de integratieconfiguratie zijn aangepast. Sla waar nodig een gecontroleerde representatie op, voer de beleidscontrole vlak voor verbinding opnieuw uit en leg vast welke gebruiker of integratie het verzoek heeft aangevraagd. Zo zijn bevoegdheden en bestemming beter te beoordelen wanneer een taak onverwacht netwerkverkeer veroorzaakt.
SSRF-tests, logging en foutafhandeling in de praktijk
Test SSRF-beveiliging op de volledige keten: invoerveld, URL-parser, DNS-resolutie, HTTP-client, redirects, proxy en netwerkregels. Gebruik in een testomgeving gecontroleerde adressen en DNS-antwoorden om publieke, interne, loopback- en IPv6-situaties na te bootsen. Controleer varianten met afwijkende schrijfwijzen, redirects naar verboden hosts en meerdere DNS-antwoorden. Test ook gedrag bij time-outs, lege responses en grote bestanden; zulke omstandigheden kunnen een beveiligingscontrole indirect uitschakelen of een worker langdurig bezet houden.
Een nuttige test verifieert niet alleen dat een aanvraag wordt afgewezen, maar ook dat er geen verbinding met de verboden bestemming is gemaakt. Instrumenteer daarom de client of netwerklaag in tests. Neem regressietests op wanneer een parser, HTTP-library, proxy of runtime wordt gewijzigd, omdat standaardinstellingen rond DNS, redirects en protocolondersteuning kunnen veranderen. Test de configuratie die in productie draait, niet alleen een geïsoleerde validatiefunctie.
Log voldoende gegevens om incidenten te onderzoeken: de aanvragende functie, genormaliseerde host, resolved IP, redirectstap en uitkomst. Vermijd het opslaan van volledige querystrings of response-inhoud wanneer daar tokens of persoonsgegevens in kunnen staan. Geef gebruikers een algemene foutmelding, maar houd technische details beschikbaar in afgeschermde logs. Limieten op responstijd, bestandsgrootte en redirects beschermen daarnaast de beschikbaarheid van workers, ook wanneer een verzoek niet op een intern doel uitkomt.
Veelgestelde vragen
Hoe test ik een applicatie veilig op SSRF?
Test op SSRF alleen met toestemming en gebruik een gecontroleerde bestemming die je zelf beheert. Voer tests bij voorkeur uit in een testomgeving, zodat je geen interne systemen of productiegegevens raakt. Een unieke URL of token op je eigen testdomein kan laten zien of de server een verzoek uitvoert, zonder dat je gevoelige bestemmingen hoeft te benaderen.
- Leg vooraf de scope en het testmoment vast.
- Gebruik geen cloudmetadata-adressen of willekeurige interne IP-adressen als testdoel.
- Stop als je onverwacht toegang krijgt tot gegevens of diensten en meld de bevinding volgens de afgesproken procedure.
Welke signalen wijzen op een SSRF-aanval in serverlogs?
Onverwachte uitgaande verzoeken naar interne, lokale of ongebruikelijke bestemmingen kunnen wijzen op SSRF, maar zijn op zichzelf geen bewijs van een aanval. Vergelijk webverzoeken met DNS-, proxy- en netwerklogs om te zien welke invoer een uitgaande verbinding voorafging. Let ook op herhaalde verzoeken naar verschillende hosts, onverwachte URL-schema’s en foutmeldingen of responstijden die veranderen na invoer van een adres.
- Registreer waar toegestaan de aangeleverde URL, de opgeloste host en het uiteindelijke bestemmingsadres.
- Onderzoek afwijkingen in uitgaand verkeer en ongebruikelijke redirectketens.
- Beperk gevoelige gegevens in logs en stel meldingen in op afwijkende bestemmingen.
Wat moet ik doen als ik vermoed dat SSRF is misbruikt?
Beperk eerst verdere uitgaande verzoeken vanuit de betrokken applicatie en onderzoek daarna welke bestemmingen zijn benaderd. Bewaar relevante applicatie-, DNS-, proxy- en netwerklogs voordat tijdelijke maatregelen gegevens laten verdwijnen. Behandel mogelijk blootgestelde tokens of inloggegevens als gecompromitteerd: trek ze in of roteer ze en controleer welke acties ermee zijn uitgevoerd.
- Isoleer zo nodig de getroffen workload of schakel de risicovolle functie tijdelijk uit.
- Controleer cloud- en interne diensten op verdachte verzoeken of wijzigingen.
- Herstel de oorzaak en test de aangepaste controles voordat je de functie weer vrijgeeft.
Wat is het verschil tussen SSRF en CSRF?
Bij SSRF laat een aanvaller de server van een applicatie een verzoek uitvoeren, terwijl CSRF een browser van een ingelogde gebruiker verleidt om een ongewenste actie uit te voeren. SSRF bedreigt vooral bestemmingen die vanaf de server bereikbaar zijn; CSRF misbruikt vooral de sessie en rechten van de gebruiker in diens browser. De afkortingen lijken op elkaar, maar de aanvaller richt zich dus op een ander onderdeel van het systeem.
- SSRF vraagt om beperkingen op serververzoeken en netwerktoegang.
- CSRF wordt onder meer tegengegaan met CSRF-tokens en passende cookie-instellingen.
Kan een WAF SSRF-aanvallen blokkeren?
Een WAF kan bepaalde verdachte invoer herkennen, maar biedt op zichzelf geen betrouwbare bescherming tegen SSRF. Een aanval kan bijvoorbeeld gebruikmaken van ongebruikelijke URL-notaties, redirects of DNS-resolutie die pas na de WAF-controle plaatsvindt. Bovendien ziet een WAF niet noodzakelijk welk IP-adres de server uiteindelijk benadert. Gebruik een WAF daarom hoogstens als aanvullende detectie- of blokkeerlaag.
- Valideer bestemmingen in de applicatie met dezelfde interpretatie als de HTTP-client.
- Beperk uitgaand verkeer op netwerk- of proxyniveau.
- Test of verzoeken naar verboden bestemmingen ook worden tegengehouden wanneer de WAF ze doorlaat.
