SSRF verstehen – Teil 5: Schutzmaßnahmen & Best Practices

Sep. 12, 2025

—

von

Stefan

in Cyber Security, SSRF, Websecurity

Grundprinzipien der Verteidigung

Eingaben niemals blind vertrauen
Jede URL, die ein User eingibt, kann bösartig sein.
Allowlist statt Blacklist
- Blacklists („blocke localhost, 127.0.0.1“) sind unvollständig.
- Besser: Nur explizit erlaubte Domains und Protokolle zulassen.
Verbindungen einschränken
- Server sollten nicht ins gesamte Internet „sprechen“ dürfen.
- Egress-Firewalls & Proxy-Whitelists einsetzen.
Cloud-spezifische Controls nutzen
- AWS: IMDSv2 erzwingen
- Azure: NSGs restriktiv setzen
- GCP: Metadata-Concealment und VPC Service Controls

Konkrete Schutzmaßnahmen im Code

1) Erlaube nur HTTP(S)

Alles andere blockieren (file://, gopher://, ftp:// …).

Python (safe parser):

from urllib.parse import urlparse

def validate_scheme(url):
    parsed = urlparse(url)
    if parsed.scheme not in {"http", "https"}:
        raise ValueError("Only HTTP/HTTPS allowed")
    return parsed

2) Hostname prüfen & DNS auflösen

Nur bekannte Domains akzeptieren, IPs und interne Netzwerke blocken.

Python-Beispiel:

import ipaddress, socket

def is_private_ip(hostname):
    try:
        for res in socket.getaddrinfo(hostname, None):
            ip = res[4][0]
            ip_obj = ipaddress.ip_address(ip)
            if ip_obj.is_private or ip_obj.is_loopback:
                return True
        return False
    except socket.gaierror:
        return True  # lieber blocken als durchlassen

3) Redirects kontrollieren

Jeder Redirect muss erneut geprüft werden.
Viele Angriffe nutzen Open Redirects, um Filter zu umgehen.

4) Egress-Kontrolle auf Infrastrukturebene

Selbst wenn die App einen Fehler hat:

Container oder VM dürfen nur ins Internet (z. B. CDN, API)
keine internen Netze (10.x.x.x, 192.168.x.x)
keine Cloud-Metadata IP (169.254.169.254)

Das kann durch Firewall-Regeln, Kubernetes-NetworkPolicies oder Proxy-Whitelists erzwungen werden.

5) Zusätzliche Härtung

Timeouts setzen (timeout=5) → verhindert, dass Requests hängen bleiben.
Antwortgrößen limitieren → schützt vor DoS.
Keine sensiblen Header durchreichen (z. B. Set-Cookie, Authorization).
Logging & Monitoring: Jede ungewöhnliche Abfrage auf interne Ziele sollte Alarm schlagen.

Entwickler-Checkliste

✅ Do

Explizite Allowlist für Domains
Nur http:// und https:// erlauben
IP-Adressen auflösen und prüfen (keine privaten/Loopback)
Redirects streng prüfen oder verbieten
Egress-Firewall einsetzen
Cloud-Metadata blockieren, wenn nicht nötig
Minimalprivilegien für Rollen/Service Accounts

❌ Don’t

Niemals User-Eingaben blind an requests.get() / file_get_contents() weiterreichen
Keine Blacklist auf einzelne Strings („localhost“)
Keine Proxy-Umgebungsvariablen erlauben (HTTP_PROXY, NO_PROXY)
Keine schwachen Defaults wie verify=False bei HTTPS
Kein „alles offen lassen und auf Logging hoffen“

Fazit

SSRF ist eine der mächtigsten Web-Schwachstellen, weil sie den Server selbst als Einfallstor nutzt.
In der Cloud wird es besonders gefährlich, da Metadata Services kompromittiert werden können → Cloud-Konten sind dann im schlimmsten Fall komplett übernommen.
Mit einer Kombination aus Allowlists, DNS/IP-Prüfungen, Egress-Firewalls und Cloud-spezifischen Controls lässt sich das Risiko jedoch stark reduzieren.