Web-Sicherheitsgrundlagen: SSRF, CSRF und CORS erklärt

In der modernen Weblandschaft ist Sicherheit nicht nur ein Feature – sie ist das Fundament. Da Anwendungen immer stärker vernetzt sind, ist es für jeden Entwickler entscheidend, die Nuancen zu verstehen, wie Anfragen über verschiedene Ursprünge und Server hinweg verarbeitet werden.

Heute tauchen wir in drei kritische Konzepte ein, die jeder Webentwickler beherrschen sollte: SSRF, CSRF und CORS. Obwohl sie wie Buchstabensuppe klingen mögen, repräsentieren sie die vorderste Front der Webanwendungssicherheit.

1. SSRF (Server-Side Request Forgery)

SSRF ist eine Schwachstelle, bei der ein Angreifer eine serverseitige Anwendung dazu zwingen kann, HTTP-Anfragen an eine beliebige Domäne seiner Wahl zu stellen.

Wie es funktioniert

Stellen Sie sich eine Webanwendung vor, die eine URL als Eingabe entgegennimmt (z. B. um ein Profilbild abzurufen oder eine Linkvorschau zu erstellen) und dann eine Anfrage an diese URL vom Server aus stellt. Wenn die Anwendung diese URL nicht ordnungsgemäß validiert, könnte ein Angreifer eine interne IP-Adresse oder eine Loopback-Adresse (127.0.0.1) angeben.

Der Server, der als Proxy fungiert, könnte dann sensible Daten von internen Diensten abrufen, die nicht dem öffentlichen Internet ausgesetzt sind, wie zum Beispiel:

• Cloud-Metadaten: Zugriff auf 169.254.169.254 bei AWS/GCP, um IAM-Zugangsdaten abzurufen.
• Interne Admin-Panels: Zugriff auf interne Tools wie Jenkins oder Kubernetes-Dashboards.
• Port-Scanning: Entdecken anderer Dienste, die im internen Netzwerk laufen.

Prävention

• Allowlisting: Erlauben Sie nur Anfragen an eine vordefinierte Liste vertrauenswürdiger Domänen.
• Eingabevalidierung: Stellen Sie sicher, dass die URL erlaubte Protokolle verwendet (z. B. nur https://) und nicht auf interne IP-Bereiche verweist.
• Netzwerksegmentierung: Stellen Sie sicher, dass der Webserver nur eingeschränkten Zugriff auf interne Ressourcen hat.

2. CSRF (Cross-Site Request Forgery)

CSRF ist ein Angriff, der den Browser eines Opfers dazu verleitet, eine ungewollte Aktion auf einer anderen Website auszuführen, bei der das Opfer derzeit authentifiziert ist.

Wie es funktioniert

Dieser Angriff nutzt die Tatsache aus, dass Browser automatisch Umgebungsinformationen – wie Session-Cookies – bei jeder Anfrage an eine Domäne mitsenden.

1. Ein Benutzer meldet sich bei bank.com an.
2. Der Benutzer besucht eine bösartige Seite evil.com in einem anderen Tab.
3. evil.com enthält ein verstecktes Formular, das eine POST-Anfrage an bank.com/transfer?amount=1000&to=attacker sendet.
4. Der Browser sendet die Anfrage zusammen mit dem Session-Cookie des Benutzers für bank.com.
5. bank.com sieht eine gültige Sitzung und verarbeitet die Überweisung.

Prävention

• Anti-CSRF-Token: Fügen Sie jeder zustandsändernden Anfrage ein eindeutiges, geheimes und unvorhersehbares Token hinzu. Der Server überprüft dieses Token vor der Verarbeitung.
• SameSite-Cookies: Setzen Sie das Attribut SameSite bei Cookies auf Strict oder Lax, um zu verhindern, dass sie bei websiteübergreifenden Anfragen gesendet werden.
• Benutzerdefinierte Header: Verlangen Sie für AJAX-Anfragen einen benutzerdefinierten Header (z. B. X-Requested-With), der nicht durch ein Standard-HTML-Formular gesetzt werden kann.

3. CORS (Cross-Origin Resource Sharing)

Im Gegensatz zu SSRF und CSRF ist CORS an sich keine Schwachstelle, sondern ein Sicherheitsmechanismus. Es ist eine Möglichkeit für Server, dem Browser mitzuteilen: “Es ist in Ordnung, wenn dieser spezifische externe Ursprung auf meine Ressourcen zugreift.”

Warum es existiert

Standardmäßig erzwingen Browser die Same-Origin-Policy (SOP), die verhindert, dass ein Skript auf einer Website Daten von einer anderen Website liest. Dies verhindert, dass evil.com Ihre E-Mails auf gmail.com liest.

CORS ermöglicht es Servern, diese Richtlinie sicher zu lockern. Wenn eine Web-App eine ursprungsübergreifende Anfrage stellt, sendet der Browser einen Origin-Header. Der Server antwortet mit Access-Control-Allow-Origin.

Häufige Fehlkonfigurationen

• Wildcard-Ursprung (*): Erlaubt alle Ursprünge. Während dies für öffentliche APIs in Ordnung ist, ist es gefährlich, wenn es mit Access-Control-Allow-Credentials: true kombiniert wird.
• Spiegeln des Ursprungs: Dynamisches Setzen des erlaubten Ursprungs basierend auf dem Origin-Header ohne Validierung. Dies umgeht die SOP effektiv vollständig.

Best Practices

• Seien Sie spezifisch: Erlauben Sie nur die spezifischen Domänen, die Zugriff benötigen.
• Vermeiden Sie Zugangsdaten, wenn möglich: Wenn Ihre API keine Cookies oder Authorization-Header benötigt, erlauben Sie diese nicht.
• Verwenden Sie eine Sicherheits-Middleware: Verwenden Sie gut getestete Bibliotheken für die CORS-Konfiguration, anstatt Header manuell zu verwalten.

Zusammenfassender Vergleich

Das Verständnis dieser drei Säulen der Web-Sicherheit ist für den Aufbau robuster, moderner Anwendungen unerlässlich. Durch die Implementierung von Defense-in-Depth-Strategien können Sie sowohl die interne Infrastruktur Ihres Servers als auch die privaten Daten Ihrer Benutzer schützen.

Bleiben Sie sicher und viel Spaß beim Programmieren!