SSRF is een probleem met cloudidentiteit, niet alleen met URL-filters

Kort samengevat: Server-side request forgery kan een onschuldige ophaalfunctie veranderen in toegang tot interne diensten en cloudreferenties. Duurzame verdediging beperkt bestemmingen, redirects, DNS-resolutie en workloadidentiteit gezamenlijk.

De kwetsbare functie lijkt vaak onschuldig

Applicaties halen externe inhoud op voor linkvoorbeelden, webhooks, documentimport, beeldverwerking en beveiligingsscans. Het gevaar ontstaat zodra een aanvaller een deel van de bestemming beheerst en de server netwerken kan bereiken die voor de aanvaller niet toegankelijk zijn. De applicatie wordt dan een proxy die het vertrouwen van de server meeneemt naar de interne omgeving.

Een korte lijst met geblokkeerde tekenreeksen is onvoldoende. Alternatieve IP-notaties, IPv6-vormen, redirects, gebruikersinformatie in URL's en DNS-rebinding kunnen een ogenschijnlijk openbare URL na de validatie alsnog omzetten in een verzoek naar een loopbackadres, privédienst of cloudmetadata-endpoint.

Valideer iedere netwerkbeslissing

• Sta alleen noodzakelijke schema's en poorten toe en weiger referenties, fragmenten, dubbelzinnige hostnotatie en niet-canonieke adresvormen.
• Los de hostnaam op, classificeer ieder geretourneerd adres en weiger loopback-, privé-, link-local-, multicast- en gereserveerde bereiken voor zowel IPv4 als IPv6.
• Valideer iedere redirectbestemming opnieuw en koppel de verbinding aan het gevalideerde adres, zodat DNS niet kan veranderen tussen de controle en het verzoek.
• Beperk responsomvang, contenttype, time-out en het aantal redirects, zodat een toegestane fetch geen pad naar uitputting van middelen wordt.

Netwerkmaatregelen moeten applicatiecontroles ondersteunen

Applicatievalidatie verandert voortdurend en kan achteruitgaan. Daarom heeft de runtime een onafhankelijke egress-grens nodig. Een aparte ophaaldienst met een beperkte allowlist, een geïsoleerd netwerkpad en zonder toegang tot productie-controlplanes verkleint drastisch wat een parserfout kan bereiken.

Ook bescherming van cloudmetadata is belangrijk. Vereis waar mogelijk sessiegerichte metadataprotocollen, blokkeer metadataroutes op netwerkniveau en geef de ophalende workload de kleinst mogelijke identiteit. Zelfs wanneer een verzoek een intern endpoint met referenties bereikt, hoort daar weinig of niets bruikbaars te stelen te zijn.

Test categorieën omzeilingen, niet één payload

Eén verzoek naar een bekend metadata-adres is slechts een rooktest. Een volledige SSRF-testsuite dekt coderingstrucs, decimale en hexadecimale adressen, gemengde IPv6-notatie, redirectketens, DNS-wijzigingen, verschillen tussen parsers en interne hostnamen. De suite controleert ook dat fouten geen timinginformatie of delen van de responsbody lekken.

De proof-first-aanpak van KENSAI registreert zowel de classificatie van de bestemming als het werkelijk verbonden adres. Zo wordt een schijnbare blokkade verifieerbaar bewijs dat het verzoek de bedoelde netwerkgrens nooit heeft overschreden.

Conclusie

Behandel het ophalen van externe inhoud als bevoorrechte netwerktoegang. Valideer bestemmingen en koppel verbindingen eraan, controleer redirects opnieuw, beperk egress en minimaliseer workloadidentiteit, zodat één parserfout niet kan uitgroeien tot een cloudcompromis.