Cross-Site-Scripting

Hierbei übermittelt der Angreifer zunächst selber entsprechend gewählten HTML-Code an die Webanwendung. Diese speichert den Code und fügt ihn späteren Anfragen anderer Benutzer an, ohne den HTML-Code zu maskieren. Diese Schwachstelle bezeichnet man als Cross-Site-Scripting (XSS). Die Cross-Site-Request-Forgery besteht darin, wie der Webbrowser des Opfers mit dem HTML-Code umgeht. Dieser besteht beispielsweise aus einem img-Tag, mit dem ein Webbrowser angewiesen wird, automatisch eine Grafik für die Seite nachzuladen. Anstelle der URL, unter der die Grafik zu finden ist, wird der Angreifer hier die manipulierte Anfrage einfügen. Sobald der Webbrowser des Opfers die URL aufruft, wird also die manipulierte Anfrage abgesendet und von der Webanwendung so verarbeitet, als wäre er vom Opfer autorisiert. Anstelle eines img-Tags mit einer manipulierten URL kann der Angreifer auch JavaScript-Code in die Seite einbauen. Damit ließe sich auch die unten beschriebene Abwehrmaßnahme eines Shared Secrets unterwandern.

Unterschieben der URL

Neben der Möglichkeit, den Aufruf der manipulierten URL über Cross-Site-Scripting zu automatisieren, kann der Angreifer auch aus einer Reihe anderer Möglichkeiten wählen, um das Opfer zum Aufruf einer manipulierten URL zu bewegen. Dabei wird die URL üblicherweise entweder per E-Mail an das Opfer übermittelt oder findet sich auf einer Webseite, die nicht einmal Teil der betroffenen Webanwendung zu sein braucht. Im Gegensatz zum Cross-Site-Scripting muss der Angreifer aber (je nach Gutgläubigkeit des Opfers mehr oder weniger) Überredungskunst einsetzen, um das Opfer zum Aufruf der URL zu bewegen, was auch als Social Engineering bezeichnet wird. Dabei kann die manipulierte URL zu Täuschungszwecken entweder mittels URL-Spoofing verfremdet sein oder durch einen Kurz-URL-Dienst verschleiert werden. Wählt der Angreifer E-Mail als Medium, kann er mittels E-Mail-Spoofing zusätzlich um das Vertrauen des Opfers werben, indem er sich etwa als Administrator der betroffenen Webanwendung ausgibt.

Möchte der Angreifer verhindern, dass das Opfer nach dem erfolgreichen Angriff von dem Vorgang erfährt, kann der Angreifer auch zunächst die URL einer eigenen Seite angeben, die beispielsweise ein lustiges Bild enthält. In diese Seite wird der Angreifer dann aber einen versteckten Frame einbauen, in dem dann der Aufruf der manipulierten URL stattfindet. Nutzt das Opfer ein E-Mail-Programm, das ungefragt auch in der E-Mail eingebettete Bilder über den Webbrowser aus dem Internet nachlädt, könnte man hiermit diese Angriffsmethode auch ausnutzen, ohne auf die aktive Mitwirkung des Opfers angewiesen zu sein.

All diese Methoden setzen aber voraus, dass der Benutzer bereits bei der betroffenen Webanwendung angemeldet ist, seine Zugangsdaten in einem Cookie gespeichert hat oder der Aufforderung nachkommt, sich gegenüber der Webanwendung zu authentisieren. Während letzterer Fall bei einem gesunden Maß an Menschenverstand eher unwahrscheinlich ist, stellt insbesondere die erste Situation für den Angreifer eine reelle Chance auf Erfolg dar, da viele Webanwendungen dem Anwender anbieten, seine Zugangsdaten aus Komfortgründen in dessen Webbrowser zu speichern.

Local Exploit

Hat der Angreifer die Kontrolle über den Computer des Opfers durch eine dort laufende Schadsoftware, kann er ebenfalls eine CSRF ausführen. Dazu muss die Schadsoftware lediglich den Browser anweisen, die manipulierte URL aufzurufen, was mit geringen Programmierkenntnissen keine Hürde darstellt. Die Schwierigkeit bei diesem Angriff besteht vielmehr darin, eine für den Angriff geeignete Schadsoftware auf dem Computer des Opfers zu installieren. Da dies aber nicht spezifisch für den hier geschilderten Angriff ist, soll hier auch nicht näher darauf eingegangen werden.

Serverseitig

Jede Transaktion der Webapplikation muss mit einer weiteren – dem Browser und der Webanwendung – gemeinsamen geheimen Information versehen werden.

<input type="hidden" name="csrftoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />

@using (Html.BeginForm("ChangePassword", "Manage"))
{
    // ...
}

<form action="/" method="post">
    @Html.AntiForgeryToken()
</form>

services.AddAntiforgery(options => {
    options.FormFieldName = "csrftoken";
    options.RequireSsl = true;
});

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2017 10:25:33 GMT; Max-Age=31449600; Path=/

services.AddAntiforgery(options => {
    options.CookieName = "Csrf-Token";
    options.CookiePath = "/";
    options.CookieDomain = "example.com";
    options.RequireSsl = true;
});

services.AddAntiforgery(options => {
    options.HeaderName = "X-Csrf-Token";
    options.RequireSsl = true;
});

Clientseitig

Der Benutzer einer Webanwendung muss sicherstellen, dass sein Computer frei von Schadsoftware ist. Gegen ein Programm, das im Kontext des Benutzers auf dem Client ausgeführt wird, ist jede serverseitige Abwehrmaßnahme zwecklos.

Die folgenden Hinweise sind unnötig, wenn die serverseitige Sicherheit gewährleistet ist. Da der Anwender dies aber nie sicherstellen kann, werden sie der Vollständigkeit halber mit aufgeführt:

Viele Webanwendungen, wie zum Beispiel auch die Wikipedia, bieten ihren Nutzern die Möglichkeit, dauerhaft angemeldet zu sein. Technisch wird hierbei in der Regel der in einem Cookie gespeicherte Sitzungsbezeichner am Ende einer Sitzung nicht gelöscht. Diese Komfortfunktion vergrößert aber auch die Angriffsfläche, da der Angreifer nicht mehr einen Zeitpunkt abzupassen braucht, zu dem sein Opfer an der Webanwendung angemeldet ist. Der Verzicht auf diese Funktion erhöht folglich die Hürden, die der Angreifer nehmen muss.

Möchte der Angreifer eine XSS-Lücke ausnutzen, um die Sicherheitsvorkehrung eines Shared Secrets zu umgehen, ist er darauf angewiesen, dass im Browser des Opfers JavaScript oder JScript aktiviert sind. Das Deaktivieren kann folglich ebenfalls die Angriffsfläche verringern; in der Regel nutzen aber viele Webanwendungen diese clientseitigen Skriptsprachen selber, so dass dies nicht möglich ist.

Nur HTTP-Post akzeptieren

Ein CSRF-Angriff kann nicht dadurch verhindert werden, dass Anfragen, die zu einer Veränderung von Daten führen, nur per HTTP-POST akzeptiert werden. Auch per HTTP-POST kann ohne weiteres eine gefälschte Anfrage abgesetzt werden. Dazu erstellt der Angreifer eine Seite, auf die er das Opfer lockt. Dort wird die manipulierte Anfrage entweder mittels einer clientseitigen Skriptsprache wie zum Beispiel JavaScript erzeugt, oder der Angreifer bringt das Opfer dazu, auf einen Button oder ein Bild zu klicken, wodurch die Anfrage abgesetzt wird. Wählt der Angreifer als Ziel (target-Parameter) des Formulars einen unsichtbaren Frame oder Inlineframe, sind auch hier die Chancen gering, dass das Opfer den Angriff bemerkt.

HTTP-Referrer-Prüfung

Die Prüfung des HTTP-Referrer-Headers bietet zwar einen gewissen Schutz vor reinen CSRF-Angriffen, da gefälschte Anfragen, die von einem Angreifer mittels Täuschung des Opfers auf einer externen Webseite ausgelöst wurden, zum Teil blockiert werden können. Die Webanwendung ist jedoch gut beraten, sich nicht auf den Schutz des Referrers zu verlassen: Viele Browser-Plugins erlauben es nämlich, Anfragen mit beliebigem Referrer abzusetzen, z. B. das weit verbreitete Adobe Flash (in etwas älteren Versionen). Außerdem können Benutzer oder auch Proxy-Server aus Datenschutzgründen das Übertragen des Referrers unterbinden oder gezielt einen anderen Wert eintragen, wodurch die Web-Anwendung nicht mehr allen legitimen Anwendern offensteht (false positives). Aus Gründen der Benutzbarkeit einer Webanwendung sollte man grundsätzlich gar nicht den Referrer-Header für eine HTTP-Anfrage verwenden.