Sichere Programmierung von Web-Anwendungen - Cross-Site Request Forgery - CSRF

Hinzugefügt am 24.11.2020 von Frank Hissen

Zahlreiche erfolgreiche Angriffe auf bekannte Web-Anwendungen finden wöchentlich Einzug in einschlägige Medien. Grund genug bei der Entwicklung eigener Anwendung - egal ob zur rein internen Nutzung oder mit öffentlichem Zugang - sich mit den Hintergründen der "Web Application Security" zu beschäftigen.

Dies ist ein Auszug aus dem Buch "Sicherheit von Web-Anwendungen: Für Software-Entwickler und Software-Projektleiter", auch als eBook erhältlich
Es ist ebenfalls ein zugehöriger Online-Kurs erschienen: Onlinekurs Sicherheit von Web-Anwendungen, auch verfügbar auf Udemy, und als HTML5/SCORM/mit Audiokommentar auf Anfrage

Beschreibung

Browser erlauben HTML-Formulare zu definieren, die andere Endpunkte ansteuern als die aktuelle Domain oder URL. Dies kann von maliziösen Seiten genutzt werden, um Benutzern Aktionen auf anderen Seiten unterzujubeln bei denen sie aktuell eingeloggt sind (CSRF).

Hierbei sind explizit keine Aktionen gemeint, die nur Daten abrufen, weil ein Angreifer auf diese Weise nicht an Informationen gelangen kann. Betroffen sind alle Daten- oder Zustandsänderungen.

Beispiel mit Sicherheitslücke:

Als ein vereinfachtes Beispiel für einen CSRF-Angriff stelle man sich eine Web-Anwendung vor, die Nutzern Geldtransfers untereinander erlaubt. Eine solcher Transfer erfolge über folgenden HTTP-GET-Request:

Da dieser Request lediglich einen Login erfordert, aber keinen weiteren Schutz bietet, kann er von jeder beliebigen Seite ausgelöst werden, mit der ein eingeloggter Nutzer interagiert. Dem Angreifer sind hier keine kreativen Grenzen gesetzt, um den Nutzer zur Ausführung eines maliziösen Requests zu verleiten. Beispielsweise könnte er einen Bild-Tag verwenden, so dass der Besuch seiner Seite bereits genügt:

Beim Aufruf der maliziösen Seite wird vom Browser automatisch die aktuelle Session-ID für "example.com" genutzt und die entsprechende Transaktion ausgelöst. "365884666885" sei hier die "Kontonummer" des Angreifers.
Natürlich wird gar kein Bild angezeigt, das Ziel ist ja lediglich der Auslöser des Requests.

Sichere Programmierung:

1)

Wichtige Transaktionen (insbesondere Daten-verändernde) dürfen nicht per HTTP-GET ausführbar sein.

2)

Um HTTP-POST-basierende Web-Formulare gegen CSRF abzusichern, müssen "Einmal-Formulare" erzeugt werden. Die gängigste Technik, um dies zu realisieren, ist CSRF-Tokens innerhalb von versteckten Formularfeldern (Textfeld mit Attribut "hidden") einzufügen und serverseitig mit dem Formular zu validieren. Alternativ kann auch für JavaScript- oder AJAX-basierte Requests entsprechend ein eigener Parameter definiert oder ein eigener HTTP-Header zur Auswertung gesetzt werden.

Manche Programmierframeworks oder Middlewares (z.B. Apache) bieten von Hause aus CSRF-Tokens zur Konfiguration an. Dies mag jedoch bei vielen Individualanwendungen zu schwerfällig sein.

CSRF-Tokens müssen folgende Eigenschaften aufweisen:

• Zufällige Zeichenkette mit ausreichender Länge
• Nicht vorhersagbar (falsch: einfache Zusammenstellung aus Username und einfachem Zahlencounter)
• Wird mindestens mit jeder User-Session neu generiert, besser: mit jedem Formular individuell generiert und ausgeliefert
• Jede Auswertung eines betreffenden Requests validiert das aktuell gültige CSRF-Token

In der einfachsten Form kann man sich CSRF-Tokens als TANs vorstellen, die serverseitig an die aktuelle Nutzer-Session gebunden werden. Diese werden zusammen mit Web-Formularen oder JavaScripts an den jeweiligen Nutzer ausgeliefert, wenn dieser die eigene Seite besucht. Damit sind nur Requests erfolgreich ausführbar, die von der eigenen Seite stammen. Alle anderen werden verworfen.

Ähnlich wie TANs im Einsatz bei z.B. Aktiengeschäften, kann man individuelle TANs je Transaktion (hier: Web-Formular) verwenden, was einen hohen Grad an Sicherheit bedeutet. Alternativ wird eine einzige Session-TAN verwendet, die für die gesamte Session Gültigkeit besitzt. Hierbei ist das gewünschte Sicherheitsniveau individuell abzuwägen.

Ein Session-Token darf NICHT einfach die Session-ID sein!
(Diese darf nicht im HTML eingebunden sein.)

Schlagworte

Sicherheitslücke, CSRF, OWASP, Sichere Programmierung, Web-/Anwendungssicherheit, Secure Programming, Web Application Security, Softwarentwicklung, Projekt-Management, Security Awareness

Kategorien: IT-Sicherheit Hintergrundartikel Programmieren/Java

---

Kommentare

Eigenen Kommentar hinzufügen

Teilen / Weiterempfehlen

Wenn Sie diese Seite gut finden, teilen Sie es doch ihren Kontakten mit:

reddit Digg StumbleUpon XING
WhatsApp Telegram