Wat is SSRF en hoe beperk je het risico?
Auteur: Redactie Domeny.ForSale Gepubliceerd
In het kort: SSRF (Server-Side Request Forgery) is een kwetsbaarheid waarmee een aanvaller de server van een applicatie een verzoek kan laten versturen naar een onbedoeld adres. Zo kan de server bronnen bereiken die niet rechtstreeks via internet toegankelijk zijn, zoals diensten op het interne netwerk. Anders dan bij CSRF, waarbij de browser van de gebruiker wordt misbruikt, verstuurt bij SSRF de server zelf het verzoek.
Hoe werkt SSRF? Een eenvoudig voorbeeld
Stel je een applicatie voor waarmee je een productfoto kunt toevoegen door het adres van een afbeelding te plakken. De gebruiker geeft een URL op, het adres van een bron, waarna de server het bestand downloadt en opslaat in de catalogus van de winkel. Dat is een handige functie, maar de applicatie moet controleren waarmee ze daadwerkelijk verbinding maakt.
Als de applicatie elk adres accepteert, kan een aanvaller in plaats van een foto een dienst opgeven die alleen vanuit het netwerk van de server bereikbaar is. De applicatie wordt dan een tussenpersoon: ze verstuurt een verzoek naar een bestemming die de aanvaller zelf niet kan bereiken. Als de applicatie de ontvangen inhoud ook aan de gebruiker teruggeeft, kunnen interne gegevens uitlekken.
Je kunt dit vergelijken met een receptionist die op verzoek van wie dan ook documenten uit afgesloten ruimtes haalt. Het probleem is niet het ophalen van documenten op zich, maar het ontbreken van controle op waar ze vandaan mogen komen en aan wie ze mogen worden doorgegeven.
Gegevens ophalen van een door de gebruiker opgegeven adres is op zichzelf nog geen kwetsbaarheid. SSRF ontstaat wanneer de gebruiker een verzoek buiten de toegestane grenzen kan sturen en de applicatie de juiste beperkingen niet afdwingt.
Waar komt SSRF voor en wat kunnen de gevolgen zijn?
SSRF kan voorkomen bij elke functie die verbinding maakt met een andere bron op basis van gegevens waarover de gebruiker controle heeft. Typische voorbeelden zijn het genereren van linkvoorbeelden, het importeren van documenten, het downloaden van afbeeldingen en het maken van PDF-bestanden van webpagina’s. Een vergelijkbaar risico bestaat bij webhooks: automatische meldingen die naar een opgegeven adres worden verstuurd.
De gevolgen hangen af van de bronnen waartoe de server toegang heeft en van de manier waarop de applicatie het antwoord verwerkt. Mogelijke gevolgen zijn:
- informatie uit interne diensten uitlezen;
- achterhalen welke diensten bereikbaar zijn in het netwerk van de server;
- toegang krijgen tot metadata van de cloudomgeving, die soms authenticatiegegevens bevatten;
- handelingen uitvoeren in een dienst die verkeer uit het interne netwerk ten onrechte vertrouwt.
SSRF betekent niet automatisch dat de hele server wordt overgenomen. Het gevaar neemt wel toe als de applicatie ruime netwerktoegang heeft en interne diensten geen authenticatie vereisen.
Er bestaat ook blind SSRF, een variant waarbij de aanvaller het antwoord van de opgevraagde bron niet rechtstreeks ziet. Het niet tonen van de inhoud neemt de kwetsbaarheid niet weg: alleen al het versturen van een verzoek kan een ongewenste handeling veroorzaken of via het gedrag van de applicatie informatie prijsgeven.
SSRF en CSRF: vergelijkbare namen, andere werking
Bij CSRF (Cross-Site Request Forgery) wordt de browser van een gebruiker ertoe gebracht een ongewenst verzoek naar een applicatie te versturen. De browser kan daarbij automatisch sessiegegevens meesturen, bijvoorbeeld een cookie van een ingelogde gebruiker. Het doel is meestal om een handeling uit te voeren met de rechten van die gebruiker.
Bij SSRF verstuurt de server het verzoek en maakt de aanval gebruik van de netwerktoegang en eventuele rechten van de server. Daarvoor is niet per definitie een ingelogd slachtoffer nodig, al kan de kwetsbare functie zelf pas na het inloggen beschikbaar zijn.
| Kenmerk | SSRF | CSRF |
|---|---|---|
| Wie verstuurt het verzoek? | De server van de applicatie | De browser van de gebruiker |
| Wat wordt misbruikt? | De toegang en rechten van de server | De sessie van de gebruiker |
| Belangrijkste beschermingsmaatregel | Verbindingsdoelen en netwerktoegang controleren | Verzoeken die de toestand wijzigen controleren, onder meer met CSRF-tokens |
Deze beveiligingsmaatregelen zijn niet onderling uitwisselbaar. Een CSRF-token lost het probleem niet op van een server die gegevens ophaalt van niet-toegestane adressen. Omgekeerd vervangt het filteren van uitgaande verbindingen de bescherming van de gebruikerssessie niet.
Hoe beperk je het risico op SSRF?
Bepaal eerst of de applicatie echt gegevens van willekeurige adressen moet kunnen ophalen. Als de integratie maar één dienst betreft, is het veiliger om het adres daarvan in de configuratie op te slaan en de gebruiker alleen een identificatiecode voor de bron te laten opgeven.
Als gebruikers adressen moeten kunnen opgeven, pas dan meerdere beschermingslagen toe:
- Beperk de toegestane bestemmingen. Gebruik waar de functie dat toelaat een gesloten lijst met vertrouwde hosts, poorten en protocollen. Controleer adressen niet uitsluitend door naar een tekstfragment te zoeken.
- Controleer de IP-adressen van de bestemming. Houd rekening met IPv4 en IPv6 en blokkeer niet-toegestane bereiken, waaronder privénetwerken, lokale adressen en speciale toegangspunten tot cloudmetadata.
- Controleer omleidingen en DNS. Een adres dat veilig lijkt, kan doorverwijzen naar een verboden bron. De controle moet betrekking hebben op de daadwerkelijke bestemming van de verbinding, niet alleen op de oorspronkelijke URL.
- Beperk uitgaand verkeer. Netwerkregels moeten voorkomen dat de applicatie toegang krijgt tot diensten die ze niet nodig heeft. Stel ook tijdslimieten en limieten voor de grootte van antwoorden in.
Stuur cookies, tokens en andere authenticatiegegevens niet automatisch door naar adressen die de gebruiker opgeeft. Raadpleeg in een cloudomgeving ook de officiële documentatie van de aanbieder over het beveiligen van de metadatadienst.
Waar begin je met het controleren van de applicatie?
Maak een overzicht van de functies waarbij de server gegevens ophaalt op basis van een adres of een andere waarde die de gebruiker opgeeft. Leg voor elke functie vast welke verbindingsdoelen zijn toegestaan, hoe omleidingen worden afgehandeld en welke gegevens naar de gebruiker worden teruggestuurd.
Voer tests alleen uit in je eigen omgeving of met toestemming van de eigenaar. Begin met één functie, bijvoorbeeld het importeren van een afbeelding, en controleer of de beperkingen ook na een omleiding werken, niet alleen voor het adres dat in het formulier is ingevuld.
Zie ook: Wat betekent www?
Lees ook
