Förhindra SSRF-attacker
Lär Er att identifiera och begränsa sårbarheter för Server-Side Request Forgery (SSRF) genom att validera URL:er och begränsa utgående nätverksanrop.
Förhindra SSRF-attacker är en gratis lektion i Säker kodning och OWASP Top 10 för backend på CoddyKit. Detta är lektion 3 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Säker kodning och OWASP Top 10 för backend, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Säker kodning och OWASP Top 10 för backend innehåller totalt 4 lektioner.
Förstå SSRF-attacker
Server-Side Request Forgery (SSRF) är en allvarlig sårbarhet inom webbsäkerhet. Den lurar en server att skicka requests till en oavsedd plats, ofta interna resurser eller andra externa tjänster.
Föreställ dig att din backendapplikation fungerar som en proxy som hämtar data eller resurser åt en användare. Om en angripare kan styra vart dessa requests skickas har du en SSRF-sårbarhet.
Så fungerar SSRF
SSRF fungerar vanligtvis på följande sätt:
- Din applikation tar emot en URL från en användare.
- Servern skickar sedan en request till URL:en för att hämta data (till exempel en bild, en fil eller en webbsida).
- En angripare anger en skadlig URL som pekar på en intern IP-adress eller en känslig tjänst.
- Servern litar på indatan och skickar requesten, vilket kan exponera interna data eller tjänster.
Riskerna med SSRF
Konsekvenserna av en lyckad SSRF-attack kan vara allvarliga:
- Åtkomst till interna system: Angripare kan skanna interna nätverk och komma åt databaser eller administrativa gränssnitt.
- Exponering av molnmetadata: I molnplattformar (AWS, GCP och Azure) kan SSRF exponera känsliga instansmetadata, inklusive tillfälliga autentiseringsuppgifter.
- Interaktion med andra tjänster: Servern kan tvingas interagera med andra API:er eller tjänster som den har åtkomst till och utföra obehöriga åtgärder.
- Portskanning: Angripare kan använda servern för att skanna portar på andra interna eller externa datorer.
Sårbar kod i praktiken
Tänk på en enkel backendtjänst som hämtar innehåll från en URL som användaren anger. Detta Java-exempel visar ett vanligt mönster som kan leda till SSRF.
Metoden fetchContent använder direkt en URL från användaren för att skicka en HTTP-request utan 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();
}
}Kraften i allowlisting
Det mest robusta skyddet mot SSRF är allowlisting. I stället för att försöka blockera farlig indata bör du endast tillåta känd och säker indata.
För URL:er innebär detta att du definierar en strikt lista över tillåtna domäner, värdnamn eller IP-adresser som applikationen får ansluta till. Alla requests till destinationer som inte finns på listan ska blockeras.
Kod för allowlisting av URL:er
Vi uppdaterar vårt tidigare exempel så att det innehåller en allowlistkontroll. Vi definierar tillåtna domäner och kontrollerar URL:en mot dem innan vi skickar några nätverksrequests.
På så sätt säkerställer vi att servern endast ansluter till betrodda externa tjänster.
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();
}
}Blocklisting: en riskfylld metod
Ni kanske tror att det är enklare att svartlista kända skadliga IP-adresser eller domäner. Svartlistning är dock i grunden ett svagt skydd mot SSRF.
Angripare kan använda olika knep för att kringgå svartlistor:
- Kodning av IP-adresser: Användning av decimala, oktala eller hexadecimala representationer (till exempel
http://0x7f000001för localhost). - DNS-ombindning: Ändring av DNS-poster så att en ”säker” domän pekar på en intern IP-adress efter den första kontrollen.
- URL-förkortare: Maskering av skadliga URL:er bakom en till synes harmlös kort URL.
- Specialprotokoll: Användning av schemana
file://,gopher://ellerdata://om de inte uttryckligen blockeras.
Föredra alltid vitlistning!
Lagerindelat försvar: Nätverksregler
Utöver validering av URL:er på applikationsnivå bör Ni även införa kontroller på nätverksnivå:
- Brandväggsregler: Konfigurera brandväggar så att utgående anslutningar från applikationsservern till interna IP-intervall blockeras (till exempel
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,127.0.0.1/8). - Nätverkssegmentering: Isolera servern som gör externa förfrågningar i ett eget nätverkssegment med minimal åtkomst till andra interna resurser.
- Minsta privilegium: Säkerställ att applikationens körmiljö endast har den nätverksåtkomst som behövs.
Dessa åtgärder utgör ett viktigt andra försvarslager.
Komplexa URL:er och omdirigeringar
SSRF-attacker kan också utnyttja detaljer i hur URL:er hanteras:
- Inkonsekventa URL-parsrar: Olika bibliotek eller system kan tolka en URL på olika sätt, vilket kan göra det möjligt att kringgå Er validering. Använd alltid en konsekvent och robust parser.
- HTTP-omdirigeringar: En angripare kan ange en vitlistad URL som sedan omdirigerar till en svartlistad intern IP-adress. Applikationen måste följa omdirigeringar försiktigt och validera den slutliga destinations-URL:en på nytt.
Validera alltid den upplösta URL:en efter alla omdirigeringar och innan den slutliga förfrågan görs.
Förhindra SSRF-attacker
Vilken av följande strategier är mest effektiv för att förhindra sårbarheter av typen Server-Side Request Forgery (SSRF)?
Sammanfattning: Skydda mot SSRF
Ni har lärt Er att identifiera och förhindra SSRF-attacker!
- SSRF gör det möjligt för en server att skicka obehöriga förfrågningar till interna eller externa system.
- Det mest effektiva skyddet är vitlistning av URL:er, där anslutningar endast tillåts till betrodda destinationer.
- Undvik svartlistning, eftersom den lätt kan kringgås.
- Komplettera skydd på applikationsnivå med nätverksbrandväggar och segmentering.
- Var uppmärksam på inkonsekvenser vid URL-parsning och validera alltid URL:er på nytt efter omdirigeringar.
Håll Er backend säker genom att strikt kontrollera utgående anslutningar!
Lär dig Säker kodning och OWASP Top 10 för backend med en AI-lärare – gratis
Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.
- Kurser
- 12
- Lektioner
- 48
Vanliga frågor
Är lektionen ”Förhindra SSRF-attacker” gratis?
Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Säker kodning och OWASP Top 10 för backend, inklusive ”Förhindra SSRF-attacker”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Säker kodning och OWASP Top 10 för backend innehåller totalt 4 lektioner.
Vad lär jag mig i ”Förhindra SSRF-attacker”?
Lär Er att identifiera och begränsa sårbarheter för Server-Side Request Forgery (SSRF) genom att validera URL:er och begränsa utgående nätverksanrop. Ni övar på Säker kodning och OWASP Top 10 för backend med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.
Behöver jag någon erfarenhet för att börja lära mig Säker kodning och OWASP Top 10 för backend?
Du behöver inga förkunskaper. Utbildningen i Säker kodning och OWASP Top 10 för backend på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.
Hur lång tid tar lektionen ”Förhindra SSRF-attacker”?
De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.
Kan jag skriva och köra kod i den här Säker kodning och OWASP Top 10 för backend-lektionen?
Ja. Varje Säker kodning och OWASP Top 10 för backend-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.
Alla lektioner i den här kursen
- Utforma säkra RESTful API:er
- GraphQL API-säkerhet
- Förhindra SSRF-attacker
- Hastighetsbegränsning och throttling för API:er