Forebyggelse af SSRF-angreb
Lær at identificere og begrænse sårbarheder ved Server-Side Request Forgery (SSRF) ved at validere URL'er og begrænse udgående netværksforespørgsler.
Forebyggelse af SSRF-angreb er en gratis Sikker kodning og OWASP Top 10 til backend-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Sikker kodning og OWASP Top 10 til backend, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Sikker kodning og OWASP Top 10 til backend-kurset indeholder 4 lektioner i alt.
Forstå SSRF-angreb
Server-Side Request Forgery (SSRF) er en alvorlig websikkerhedssårbarhed. Den narrer en server til at sende forespørgsler til et utilsigtet sted, ofte interne ressourcer eller andre eksterne tjenester.
Forestil dig, at din backendapplikation fungerer som en proxy, der henter data eller ressourcer på vegne af en bruger. Hvis en angriber kan styre destinationen for disse forespørgsler, har du en SSRF-sårbarhed.
Sådan fungerer SSRF
SSRF fungerer typisk sådan:
- Din applikation accepterer en URL fra en bruger.
- Serveren sender derefter en forespørgsel til denne URL for at hente data (f.eks. et billede, en fil eller en webside).
- En angriber angiver en ondsindet URL, der peger på en intern IP-adresse eller en følsom tjeneste.
- Serveren stoler på inputtet og sender forespørgslen, hvilket potentielt afslører interne data eller tjenester.
Farerne ved SSRF
Konsekvenserne af et vellykket SSRF-angreb kan være alvorlige:
- Adgang til interne systemer: Angribere kan scanne interne netværk og få adgang til databaser eller administrative grænseflader.
- Eksponering af cloudmetadata: På cloudplatforme (AWS, GCP, Azure) kan SSRF afsløre følsomme instansmetadata, herunder midlertidige legitimationsoplysninger.
- Interaktion med andre tjenester: Serveren kan blive tvunget til at interagere med andre API'er eller tjenester, som den har adgang til, og udføre uautoriserede handlinger.
- Portscanning: Angribere kan bruge serveren til at scanne porte på andre interne eller eksterne maskiner.
Sårbar kode i praksis
Overvej en enkel backendtjeneste, der henter indhold fra en URL angivet af brugeren. Dette Java-eksempel viser et almindeligt mønster, der kan føre til SSRF.
Metoden fetchContent bruger direkte en URL leveret af brugeren til at sende en HTTP-forespørgsel uden validering.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLConnection;
public class Main {
public static void main(String[] args) {
// In a real app, this URL would come from user input (e.g., a web parameter)
String userSuppliedUrl = "http://example.com/data.txt";
// Malicious example: "http://169.254.169.254/latest/meta-data/"
try {
System.out.println("Fetching content from: " + userSuppliedUrl);
String content = fetchContent(userSuppliedUrl);
System.out.println("--- Fetched Content ---");
System.out.println(content.substring(0, Math.min(content.length(), 100)) + "...");
System.out.println("-----------------------");
} catch (Exception e) {
System.err.println("Error fetching content: " + e.getMessage());
}
}
public static String fetchContent(String urlString) throws Exception {
URL url = new URL(urlString);
URLConnection connection = url.openConnection();
BufferedReader in = new BufferedReader(
new InputStreamReader(connection.getInputStream()));
String inputLine;
StringBuilder content = new StringBuilder();
while ((inputLine = in.readLine()) != null) {
content.append(inputLine);
}
in.close();
return content.toString();
}
}Styrken ved hvidlistning
Det mest robuste forsvar mod SSRF er hvidlistning. I stedet for at forsøge at blokere dårlige input bør du kun tillade kendte og sikre input.
For URL'er betyder det, at du definerer en streng liste over tilladte domæner, værtsnavne eller IP-adresser, som din applikation må oprette forbindelse til. Alle forespørgsler til destinationer, der ikke står på denne liste, skal blokeres.
Kode til hvidlistning af URL'er
Lad os opdatere det tidligere eksempel, så det omfatter et hvidlistetjek. Vi definerer tilladte domæner og kontrollerer input-URL'en mod dem, før vi sender netværksforespørgsler.
På den måde sikrer vi, at serveren kun opretter forbindelse til eksterne tjenester, der er tillid til.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLConnection;
import java.util.Arrays;
import java.util.List;
public class Main {
private static final List<String> ALLOWED_HOSTS = Arrays.asList(
"example.com", "mytrustedapi.com"
);
public static void main(String[] args) {
String safeUrl = "http://example.com/data.txt";
String maliciousUrl = "http://badsite.com/evil.php";
try {
System.out.println("\nAttempting to fetch from: " + safeUrl);
String content = fetchContentSafely(safeUrl);
System.out.println("Fetched (safe): " + content.substring(0, Math.min(content.length(), 50)) + "...");
} catch (Exception e) {
System.err.println("Error fetching (safe): " + e.getMessage());
}
try {
System.out.println("\nAttempting to fetch from: " + maliciousUrl);
String content = fetchContentSafely(maliciousUrl);
System.out.println("Fetched (malicious): " + content.substring(0, Math.min(content.length(), 50)) + "...");
} catch (Exception e) {
System.err.println("Error fetching (malicious): " + e.getMessage());
}
}
public static String fetchContentSafely(String urlString) throws Exception {
URL url = new URL(urlString);
String host = url.getHost();
if (!ALLOWED_HOSTS.contains(host)) {
throw new IllegalArgumentException("Host not allowed: " + host);
}
URLConnection connection = url.openConnection();
BufferedReader in = new BufferedReader(
new InputStreamReader(connection.getInputStream()));
String inputLine;
StringBuilder content = new StringBuilder();
while ((inputLine = in.readLine()) != null) {
content.append(inputLine);
}
in.close();
return content.toString();
}
}Sortlistning: En risikabel tilgang
Du tror måske, at det er nemmere at blokere kendte skadelige IP-adresser eller domæner. Men blokering er grundlæggende ineffektiv mod SSRF.
Angribere kan bruge forskellige tricks til at omgå blokeringer:
- Kodning af IP-adresser: Brug af decimale, oktale eller hexadecimale repræsentationer (f.eks.
http://0x7f000001for localhost). - DNS-rebinding: Ændring af DNS-poster, så et "sikkert" domæne peger på en intern IP-adresse efter den indledende kontrol.
- URL-forkortere: Skjuler skadelige URL'er bag en tilsyneladende harmløs kort URL.
- Specielle protokoller: Brug af skemaerne
file://,gopher://ellerdata://, hvis de ikke eksplicit blokeres.
Foretræk altid tilladelseslister!
Lagdelt forsvar: Netværksregler
Ud over validering af URL'er på applikationsniveau bør du også implementere kontroller på netværksniveau:
- Firewallregler: Konfigurer firewalls til at blokere udgående forbindelser fra din applikationsserver til interne IP-intervaller (f.eks.
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,127.0.0.1/8). - Netværkssegmentering: Isoler serveren, der foretager eksterne forespørgsler, i sit eget netværkssegment med minimal adgang til andre interne ressourcer.
- Mindste privilegium: Sørg for, at applikationens runtime-miljø kun har den nødvendige netværksadgang.
Disse foranstaltninger udgør et vigtigt ekstra forsvarslag.
Komplekse URL'er og omdirigeringer
SSRF-angreb kan også udnytte nuancer i håndteringen af URL'er:
- Uensartede URL-fortolkere: Forskellige biblioteker eller systemer kan fortolke en URL forskelligt, så din validering potentielt kan omgås. Brug altid en ensartet og robust fortolker.
- HTTP-omdirigeringer: En angriber kan angive en URL på tilladelseslisten, som derefter omdirigerer til en intern IP-adresse på blokeringslisten. Din applikation skal følge omdirigeringer forsigtigt og validere den endelige destinations-URL igen.
Valider altid den opløste URL efter eventuelle omdirigeringer og før den endelige forespørgsel sendes.
Forebyggelse af SSRF-angreb
Hvilken af følgende strategier er mest effektiv til at forhindre sårbarheder ved Server-Side Request Forgery (SSRF)?
Opsummering: Beskyttelse mod SSRF
Du har lært, hvordan du identificerer og forhindrer SSRF-angreb!
- SSRF gør det muligt for en server at sende uautoriserede forespørgsler til interne eller eksterne systemer.
- Det mest effektive forsvar er tilladelseslister for URL'er, hvor forbindelser kun tillades til betroede destinationer.
- Undgå blokeringslister, da de let kan omgås.
- Supplér forsvar på applikationsniveau med netværksfirewalls og segmentering.
- Vær opmærksom på uoverensstemmelser i URL-fortolkning, og validér altid URL'er igen efter omdirigeringer.
Hold din backend sikker ved strengt at kontrollere udgående forbindelser!
Lær Sikker kodning og OWASP Top 10 til backend med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 12
- Lektioner
- 48
Ofte stillede spørgsmål
Er lektionen “Forebyggelse af SSRF-angreb” gratis?
Ja — alle 3 lektioner i læringssporet Sikker kodning og OWASP Top 10 til backend, inklusive “Forebyggelse af SSRF-angreb”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Sikker kodning og OWASP Top 10 til backend-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Forebyggelse af SSRF-angreb”?
Lær at identificere og begrænse sårbarheder ved Server-Side Request Forgery (SSRF) ved at validere URL'er og begrænse udgående netværksforespørgsler. Du øver dig i Sikker kodning og OWASP Top 10 til backend med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Sikker kodning og OWASP Top 10 til backend?
Der kræves ingen tidligere erfaring. Sikker kodning og OWASP Top 10 til backend på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.
Hvor lang tid tager lektionen “Forebyggelse af SSRF-angreb”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Sikker kodning og OWASP Top 10 til backend-lektion?
Ja. Alle Sikker kodning og OWASP Top 10 til backend-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Design af sikre RESTful-API'er
- GraphQL-API-sikkerhed
- Forebyggelse af SSRF-angreb
- Hastighedsbegrænsning og throttling af API'er