För mig blir SSRF värdefullt först när resultatet går att testa med både positiva och negativa kontrollfall. SSRF uppstår när en server gör nätverksanrop på användarens initiativ och därmed kan nå resurser som angriparen själv inte når direkt.
SSRF i praktiken
Första byggstenen: URL-allow-list är starkare än en växande deny-list. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Redirects kan flytta en tillåten URL till ett förbjudet mål. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: DNS resolution måste beaktas eftersom namn kan peka mot privata adresser. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Metadata- och management-endpoints bör skyddas även på nätverksnivå. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Arbetsgång utan genvägar
- Identifiera funktioner som hämtar URL:er, webhooks eller bilder.
- Begränsa till protokoll och destinationsdomäner som faktiskt behövs.
- Resolve och validera destination före anslutning.
- Kontrollera redirects på varje hopp.
- Blockera tjänstens nätverksåtkomst till känsliga interna zoner när den inte behövs.
För SSRF håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Ett testbart exempel
En PDF-generator som får hämta en bild-URL behöver sällan kunna nå hypervisorns managementnät eller cloud metadata. Egress-policy är därför ett värdefullt andra skydd även om URL-valideringen har en bugg.
När en bra idé blir fel i drift
- Att endast blockera textsträngen 127.0.0.1.
- Att glömma IPv6 och alternativa adressrepresentationer.
- Att validera första URL:en men följa redirect till intern destination.
Efterkontroll
För SSRF vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Privata och link-local mål nekas.
- Tillåten extern tjänst fungerar.
- Redirect från tillåtet mål till förbjudet mål stoppas.
Ett negativt test hör också till SSRF: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
SSRF – när servern blir angriparens proxy mot interna resurser handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.