SSRF og sikre URL-kald: når appen henter noget på brugerens vegne

Find alle steder, hvor serveren følger en adresse

Risikoen findes ikke kun i et felt med navnet URL. Den opstår, når en værdi fra en bruger, import eller integration påvirker, hvor backend, worker eller serverless-funktion sender et request. Gennemgå både den direkte funktion og senere baggrundsbehandling.

En adresse er stadig ubetroet, når den allerede er gemt i databasen. Kontrollér den ved hvert udgående kald, fordi konfigurationer kan ændres, DNS kan pege et andet sted, og samme værdi kan blive brugt af flere kodeveje.

Hvorfor et request fra serveren er særligt

Browseren står normalt uden for virksomhedens interne netværk. Backend kan derimod have adgang til databaser, administrationsflader, container-tjenester og cloudens lokale metadata- eller identitetstjenester. Et request, som ser harmløst ud i brugerfladen, bliver derfor sendt fra en langt mere betroet placering.

Læsning af interne svar

Et direkte SSRF-forløb kan sende indhold eller fejl tilbage til brugeren.

Blind SSRF

Selv uden synligt svar kan timing, sideeffekter og logs afsløre eller påvirke interne tjenester.

Ressourceforbrug

Langsomme eller store svar kan optage forbindelser, hukommelse, båndbredde og cloudbudget.

Appen som mellemled

Serverens IP, netværksplacering og rettigheder kan blive misbrugt mod andre mål.

Fjern den frie URL, når forretningen ikke behøver den

Den sikreste URL-vælger er ofte slet ingen URL-vælger. Hvis appen kun skal hente fra én kendt leverandør, så lad brugeren vælge konto, fil-id eller integration, mens serveren selv bygger destinationen ud fra en fast grundadresse.

• Upload frem for fjernhentning: Lad brugeren sende filen gennem den eksisterende sikre uploadfunktion, når det dækker behovet.
• Leverandørvalg frem for adresse: Gem for eksempel “Google Drive” eller “økonomisystem A” og et eksternt objekt-id, ikke en vilkårlig URL.
• Serverstyret sti: Hold protokol, værtsnavn og port faste, og indsæt kun et valideret id i den del af stien, som må variere.
• Manuel godkendelse: Hvis kundespecifikke webhookdomæner er nødvendige, kan en navngiven administrator godkende dem før første test.

Kontrollér destinationen som struktur – ikke som tekst

Brug stackens vedligeholdte URL-parser og læs protokol, værtsnavn, port og eventuelle brugeroplysninger som separate felter. En simpel kontrol af, om teksten starter eller slutter med et bestemt domænenavn, kan misforstå adresser med underdomæner, brugeroplysninger, encoding eller en anden port.

1. Tillad få protokoller. En almindelig webhentning behøver typisk HTTPS. Afvis fil-, data- og andre protokoller, som funktionen ikke kræver.
2. Tillad kendte værter og porte. Sammenlign parserens normaliserede værtsnavn med en præcis liste eller en bevidst regel for underdomæner.
3. Afvis indlejrede brugeroplysninger. En URL med brugernavn eller adgangskode kan være vildledende og kan lække credentials i logs.
4. Slå automatisk redirect fra. Hvis redirects er nødvendige, skal hvert nyt mål gennem samme kontrol, før requestet fortsætter.
5. Kontrollér den opløste IP-adresse. Afvis loopback, link-local, private og andre interne eller særlige adresser for både IPv4 og IPv6, medmindre den konkrete integration udtrykkeligt kræver dem.

Læg en netværksgrænse bag kodekontrollen

URL-validering er ét lag. Begræns også, hvad den kørende tjeneste kan nå. OWASP anbefaler at kombinere beskyttelse i applikationen med netværkskontroller, så en fejl i parser eller kode ikke automatisk giver adgang til hele det interne miljø.

• Kør vilkårlig fjernhentning i en særskilt worker eller tjeneste uden adgang til produktionsdatabasen og interne administrationsflader.
• Brug egress-regler, firewall eller proxy til kun at tillade den trafik, funktionen reelt behøver, når platformen understøtter det.
• Giv tjenestens identitet mindst mulige rettigheder. Et metadata-token er mindre farligt, hvis identiteten ikke kan læse eller ændre unødige ressourcer.
• Gennemgå cloudplatformens beskyttelse af metadata-tjenesten. Azure, AWS og Google Cloud har forskellige mekanismer; antag ikke, at samme indstilling findes overalt.

Begræns tid, størrelse og samtidighed

Et tilladt offentligt domæne kan stadig svare langsomt, sende uventet meget data eller holde forbindelsen åben. Sæt grænser i den kode, der henter, og på den platform, der kører den. Værdierne skal vælges efter funktionens normale filer og svartider.

• Brug en kort forbindelses- og samlet timeout, og afbryd læsningen aktivt, når tiden er gået.
• Begræns antal redirects, downloadstørrelse og den mængde data, der må ligge i hukommelsen.
• Kontrollér forventet medietype og filindhold; stol ikke alene på filendelse eller en ekstern Content-Type-header.
• Begræns hvor ofte en bruger kan starte hentningen, og hvor mange hentninger der må køre samtidigt.
• Send ikke det rå eksterne svar, interne fejl eller headers direkte tilbage til klienten.

Lange downloads og dokumentbehandling passer ofte bedre som et kontrolleret job end i et almindeligt webrequest. Se den separate guide om baggrundsjob og jobkøer.

Test afslag uden at angribe produktionen

Brug et isoleret testmiljø med en kontrolleret HTTP-tjeneste, som kan svare med redirects, forsinkelse, store svar og forskellige content types. Forsøg ikke at scanne interne adresser på en cloud- eller kundekonto uden udtrykkelig tilladelse.

• Bekræft at ukendt protokol, port og domæne afvises før netværkskaldet.
• Bekræft at et godkendt domæne, som redirecter til et ikke-godkendt mål, stoppes.
• Test IPv4, IPv6 og alternative URL-former mod den samme beslutningslogik.
• Test timeout, for stor respons, forkert medietype og for mange samtidige hentninger.
• Kontrollér at brugerens svar er neutralt, mens beskyttede logs viser årsag, funktion og request-id uden tokens eller følsomme query-parametre.

Typiske fejl

• Kun “localhost” blokeres: Interne mål kan have mange andre IPv4-, IPv6-, DNS- og cloud-adresser.
• Domænet findes et sted i teksten: Parseren kan se et andet værtsnavn end den hjemmelavede strengkontrol.
• Redirects er glemt: Første adresse er tilladt, men HTTP-klienten følger automatisk videre til et nyt mål.
• Kontrollen sker kun ved oprettelse: DNS, konfiguration og integrationens ejerskab kan ændre sig før næste kald.
• Hele svaret læses i hukommelsen: En stor eller uendelig strøm kan påvirke drift og regning.
• Serveren har brede cloudrettigheder: Et enkelt uventet request kan få større konsekvens end nødvendigt.
• Blokeringslisten bliver en permanent løsning: Nye specialadresser og parserformer kan omgå en liste over kendte dårlige tekststrenge.

Tjekliste til sikre udgående requests

• ☐ Alle funktioner, hvor brugerdata påvirker en udgående destination, er kortlagt.
• ☐ Fri URL er erstattet af upload, leverandørvalg eller fast serverstyret adresse, hvor det er muligt.
• ☐ En vedligeholdt URL-parser bruges til protokol, værtsnavn, port og brugeroplysninger.
• ☐ Tilladte protokoller, destinationer, porte og medietyper er defineret pr. funktion.
• ☐ Opløste IPv4- og IPv6-adresser kontrolleres mod interne og særlige netværk.
• ☐ Redirects er slået fra eller bliver valideret igen for hvert hop.
• ☐ Netværk og tjenesteidentitet kan ikke nå eller gøre mere end funktionen kræver.
• ☐ Timeout, downloadstørrelse, hukommelse, samtidighed og kald pr. bruger har realistiske grænser.
• ☐ Rå eksterne svar, headers og tekniske fejl sendes ikke direkte til klienten.
• ☐ Afslag, redirects, langsomme svar og store svar er testet i et isoleret miljø.
• ☐ Logs kan forklare et afvist kald uden at gemme tokens, credentials eller hele følsomme URL'er.

Relaterede guides

Officielle kilder

URL- og netværkskontroller afhænger af appens runtime, HTTP-klient, hosting og cloud. Følg den aktuelle dokumentation til den konkrete stack, og test den adresse, som forbindelsen faktisk bruger.

• OWASP: forebyggelse af Server-Side Request Forgery
• OWASP API Security: API7 – Server Side Request Forgery
• OWASP API Security: grænser for ressourceforbrug
• Node.js: WHATWG URL API til struktureret URL-fortolkning
• Microsoft: Azure Instance Metadata Service
• AWS: beskyt adgang til EC2 Instance Metadata Service
• Google Cloud: oversigt over metadata-serveren