SSRF verstehen – Teil 2: Praktische Beispiele aus der Praxis

---

Rückblick aus Teil 1

Wir haben gelernt: SSRF bedeutet, dass der Server Netzwerk-Requests im Auftrag des Angreifers ausführt.
Das macht die Schwachstelle so gefährlich, weil der Server:

• Zugriff auf interne Netze hat,
• Cloud-Metadaten abfragen kann,
• und Antworten oft direkt zurück an den Angreifer gibt.

Jetzt gehen wir ins Praktische.

---

Beispiel 1: PHP – Bilder laden von einer URL

Ein Entwickler möchte Bilder aus dem Internet einbinden:

<?php
if (isset($_GET['url'])) {
    $url = $_GET['url'];
    $img = file_get_contents($url);
    echo "<img src='data:image/png;base64," . base64_encode($img) . "' />";
}

Angriff

Der Angreifer ruft auf:

http://example.com/image.php?url=http://localhost:8080/admin

• Statt eines Bildes wird das interne Admin-Panel des Servers geladen.
• Da die Anwendung den Inhalt zurückgibt, sieht der Angreifer die Admin-Seite direkt im Browser.

👉 Gefährlich, weil „localhost“ für den Server selbst erreichbar ist, für den Angreifer von außen aber nicht.

---

Beispiel 2: Python (Flask + requests) – API zum Laden von Daten

Ein Entwickler baut eine API, die von einer URL Daten lädt:

from flask import Flask, request
import requests

app = Flask(__name__)

@app.route("/fetch")
def fetch():
    url = request.args.get("url")
    r = requests.get(url)
    return r.text

if __name__ == "__main__":
    app.run(debug=True)

Angriff

Der Angreifer ruft auf:

http://example.com/fetch?url=http://169.254.169.254/latest/meta-data/

• 169.254.169.254 ist die AWS-Metadaten-IP.
• Der Server gibt die Metadaten als Text zurück.
• Daraus kann der Angreifer API-Keys oder Zugangstokens stehlen.

👉 So sind in der Vergangenheit echte Cloud-Breaches passiert (z. B. Capital One 2019).

---

Beispiel 3: Node.js (Express + axios) – Proxy-Feature

In Node.js könnte ein Proxy-Service so aussehen:

const express = require("express");
const axios = require("axios");
const app = express();

app.get("/proxy", async (req, res) => {
  const url = req.query.url;
  const response = await axios.get(url);
  res.send(response.data);
});

app.listen(3000, () => console.log("Server läuft auf Port 3000"));

Angriff

Der Angreifer ruft auf:

http://example.com:3000/proxy?url=http://192.168.0.10:8080/db-console

• Der Server verbindet sich mit einem internen Datenbank-Interface (192.168.0.10).
• Die Datenbankkonsole wird zurück an den Angreifer geliefert.

👉 Für den Angreifer eine Brücke ins interne Netzwerk, obwohl er eigentlich draußen sitzt.

---

Angreifer-Techniken

SSRF endet selten beim simplen „URL austauschen“. Typische Tricks sind:

• Filter umgehen:
  Wenn Entwickler http:// oder https:// prüfen, versuchen Angreifer: http://127.0.0.1:80 http://[::1]:80 http://localhost:80
• DNS-Rebinding:
  Eine scheinbar harmlose Domain zeigt zuerst ins Internet, dann später ins interne Netzwerk.
• Andere Protokolle:
  Viele Bibliotheken erlauben neben http:// auch file://, gopher://, ftp://.
  → Damit lassen sich Dateien lesen oder sogar POST-Requests fälschen.