Bundesamt für Sicherheit in der Informationstechnik

M 4.403 Verhinderung von Cross-Site Request Forgery (CSRF, XSRF, Session Riding)

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Verantwortliche der einzelnen Anwendungen

Verantwortlich für Umsetzung: Entwickler, Administrator

Bei einem CSRF-Angriff (Cross-Site Request Forgery) wird einem Benutzer ein Befehl für eine Webanwendung ( z. B. in Form eines Links in einem Gästebuch) von einem Angreifer übermittelt. Folgt der Benutzer diesem Link, wird der Befehl an die Webanwendung gesendet und im Kontext dieses Benutzers ausgeführt. Ist der Benutzer an der Webanwendung angemeldet, so wird die Vertrauensstellung des Benutzers gegenüber der Webanwendung ausgenutzt und der Befehl mit den Rechten des Benutzers ausgeführt.

Um derartige Angriffe zu erschweren, sollte die Webanwendung Sicherheitsmechanismen unterstützen, die es ermöglichen, beabsichtigte Seitenaufrufe des Benutzers von unbeabsichtigt weitergeleiteten Befehlen Dritter zu unterscheiden. Mit den folgenden Sicherheitsmaßnahmen soll verhindert werden, dass kritische Aktionen durch CSRF-Angriffe unbeabsichtigt ausgeführt werden.

Verwendung eines zusätzlichen Tokens

Bei einem CSRF-Angriff muss ein gültiger HTTP -Request nachgestellt und an das Opfer übermittelt werden. Ein solcher HTTP-Request kann z. B. durch eine URL auf die Webanwendung abgebildet werden (z. B. http://webapp.tld/addUser?name=benutzer). Hierfür muss der Angreifer die benötigten Request-Parameter, wie z. B. GET- und POST-Variablen, für den Aufruf kennen. Diese Parameter sind im Allgemeinen leicht zu ermitteln.

Als Schutz gegen einen CSRF-Angriff kann ein geheimes Token eingeführt werden, das nur schwer vom Angreifer erraten werden kann. Bei jedem Seitenaufruf der Webanwendung wird dieses Token als Parameter in URLs oder als verstecktes Element (Hidden-Field) in Formularen mit übertragen (Double Submit Cookies). Die Webanwendung prüft bei jedem Client-Request, ob das übertragene Token mit dem zur Sitzung hinterlegten Wert übereinstimmt. Im Fehlerfall wird der angeforderte Aufruf abgelehnt. Ohne Kenntnis dieses Tokens kann ein Angreifer keinen gültigen HTTP-Request nachstellen.

Obwohl die Session ID ein vertrauliches Datum ist und daher als Token zum Schutz gegen CSRF-Angriffe eingesetzt werden könnte, sollte vorzugsweise ein separates Token erzeugt werden. Für das Token sollten dabei ähnliche Anforderungen gelten, die auch an die SessionID gestellt werden.

Wird ein CSRF-Schutz implementiert, so wird empfohlen die Funktion aus bereits verwendeten Frameworks einzusetzen, falls diese eine entsprechende Implementierungen anbieten.

Bei Webanwendungen mit hohem Schutzbedarf sollte in Betracht gezogen werden, das Token für jeden Request derart zu erzeugen, dass bei jedem Aufruf der Webanwendung ein neues Token an den Client gesendet wird, das dann im darauffolgenden Request verwendet werden muss.

Bevor kritische Aktionen ausgeführt werden (z. B. zustandsändernde Anfragen wie eine Änderung des Passworts), sollte der Benutzer erneut von der Webanwendung authentisiert werden. Hierdurch können diese Funktionen nicht unbemerkt ausgeführt werden, sondern es ist eine Interaktion mit dem Benutzer erforderlich. Webanwendungen mit hohem Schutzbedarf sollten ein Authentisierungsverfahren mit mehreren Authentisierungsfaktoren (z. B. TAN, Chipkarte) verwenden.

Alternativ kann der Benutzer beim Aufruf von kritischen Aktionen auf eine Seite umgeleitet werden, die eine Benutzerinteraktion erfordert, bevor die Aktion ausgeführt wird (z. B. die Eingabe einer zufälligen Zeichenkette). Erst nachdem der Benutzer die Interaktion ausgeführt hat (z. B. richtige Zeichenkette eingegeben), wird er weitergeleitet und die ursprüngliche Anfrage bearbeitet. Anstelle der Zeichenkette können auch andere Mechanismen eingesetzt werden, die eine Benutzerinteraktion verlangen (z. B. CAPTCHAs oder Rätselfragen, siehe auch M 4.405 Verhinderung der Blockade von Ressourcen (DoS) bei Webanwendungen und Web-Services ).

Das Referrer-Feld im HTTP-Request (die URL der Webseite, von der der Benutzer zur aktuellen Seite gekommen ist) kann als ein weiteres Sicherheitsmerkmal genutzt werden. Ein Request eines Benutzers der Webanwendung ist häufig nur dann gültig, wenn das Referrer-Feld eine URL der eigenen Webanwendung enthält. So kann davon ausgegangen werden, dass der Request durch den Klick auf einen Link der Webanwendung erzeugt wurde.

Dabei ist zu berücksichtigen, dass das Referrer-Feld deaktiviert oder gefiltert werden kann (z. B. aus Gründen des Datenschutzes) und die Maßnahme daher nicht für alle Webanwendungen umgesetzt werden kann.

Umgehung von Schutzmechanismen

Sicherheitsmechanismen zum Schutz vor CSRF-Angriffen, die auf das Referrer-Feld oder zusätzliche Tokens (siehe Abschnitt Verwendung eines zusätzlichen Tokens) basieren, können durch Cross-Site-Scripting-Angriffe umgangen werden. Die korrekte Filterung von Benutzerdaten (siehe M 4.393 Umfassende Ein- und Ausgabevalidierung bei Webanwendungen und Web-Services ) ist daher entscheidend für die Wirksamkeit der Sicherheitsmaßnahmen zum Schutz vor CSRF-Angriffen.

Mindestens eine der ersten beiden Prüffragen sollte zum Schutz vor CSRF-Angriffen umgesetzt sein:

Prüffragen:

  • Wird neben der SessionID ein geheimes Token für den Zugriff auf geschützte Ressourcen und Funktionen der Webanwendung benötigt?

  • Wird bei Webanwendungen das Referrer-Feld im HTTP-Request als zusätzliches Merkmal zur Erkennung eines beabsichtigten Aufrufs durch einen Benutzer geprüft?

  • Werden bei Webanwendungen kritische Aktionen nur nach einer erneuten Authentisierung oder einer manuellen Interaktion ausgeführt?

Stand: 13. EL Stand 2013