CSRF, dieses Kürzel taucht immer wieder in den Updatenotizen des WordPress Core auf. Die Methode, die dahintersteckt, ist mittlerweile ein alter Hut und nutzt die meist reichlich vorhandenen Cookies eines Browsers aus. Zum Glück kann man sich vor der Cross Site Request Forgery aber recht leicht schützen. Alles, was du brauchst, ist ein wenig Zeit und Aufmerksamkeit.
Du benutzt sicherlich auch eine ganze Reihe von Diensten, bei denen es die Option gibt, eingeloggt zu bleiben, selbst nachdem du die Website verlassen hast. Besuchst du die Website dann erneut, musst du deine Logindaten nicht noch einmal eingeben, sondern wirst direkt eingeloggt. Das ist natürlich super, weil es – genau wie eine Passwortverwaltung oder ein sogenannter Single Sign On – lästiges Formularausfüllen spart.
Im Hintergrund läuft dabei Folgendes ab: Wenn du dich zum ersten Mal auf der Website einloggst, hinterlegt die Website in deinem Browser ein Cookie. Es handelt sich dabei um eine kleine Textdatei, in der bestimmte Informationen gespeichert werden können. Im Fall des Eingeloggt-Bleibens ist das ein zufällig generierter String.
Bei deinem nächsten Besuch auf der Website überprüft der Server diesen String und, kann er das entsprechende Gegenstück finden, loggt dich automatisch ein. Das ist übrigens auch der Grund, weswegen du überall abgemeldet wirst, wenn du deinen Browser Cache leerst. Denn bei diesem Vorgang werden auch sämtliche Cookies gelöscht.
CSRF Attacken sind im Kern Vertrauensmissbrauch
Du merkst schon: Bei einer entsprechenden Attacke wird dem Dienst, der die Cookies ausliest, etwas vorgegaukelt. Wie genau das passiert, erkläre ich weiter unten an zwei Beispielen.
Die Gefahr dieser Manipulation liegt darin, dass jemand etwa in deinem Namen Veränderungen auf deinem Facebook Profil vornimmt. Häufig ist Cross Site Request Forgery aber auch auf Phishing angewiesen. Auch hier wird also das Vertrauen relevant – und zwar dein Vertrauen in beispielsweise die Absender von Mails.
Wie gefährdet ist WordPress?
Den Begriff Cross Site Request Forgery hast du wahrscheinlich noch nicht so oft gehört wie Brute Force Attacken oder Cross Site Scripting. Das hat auch einen Grund: Die Non Profit Organisation OWASP (Open Web Application Security Project) gibt regelmäßig eine Liste der zehn kritischsten Schwachstellen bei Webanwendungen heraus. Hierbei ist CSRF als Sicherheitsrisiko mit den Jahren immer weiter nach unten gerutscht und mittlerweile aus den Top 10 verschwunden.
Das liegt wohl unter anderem daran, dass CSRF Attacken beinahe so alt wie das Internet selber sind. Professionelle Entwickler sind mittlerweile geübt darin, ihren Code dagegen abzusichern. Sicherheitsrisiken sind also recht leicht und schnell behoben.
Bei WordPress ist man ebenfalls auf der Hut. So wurde beispielsweise im Mai das Sicherheitsupdate 4.7.5 veröffentlicht, das sechs Schwachstellen bereinigte, über die Hacker via Cross Site Scripting oder Cross Site Request Forgery einen Angriff hätten fahren können. Häufig wird dabei aber Cross Site Scripting als wesentlich gefährlicher eingeschätzt.
Zudem ist die Frage von Cross Site Request Forgery tendenziell eher für Plugins und Applikationen relevant, als für Webdesign, Agenturen und KMUs. Denn der Schutz vor CSRF ist auch eine Frage der Programmierung. Relevant könnte CSRF zum Beispiel bei In-Plugin Käufen werden.
Wie funktioniert das Ganze aber nun?
Die Anatomie von Cross Site Request Forgery
Die Grundidee hinter einem CSRF Angriff ist relativ einfach und geschieht in der Regel in zwei Schritten:
- Das Opfer wird dazu gebracht, eine manipulierte Website zu laden oder auf einen Link zu klicken, etwa indem der Anschein erweckt wird, die Nachricht sei von einer Vertrauensperson. Oder die menschliche Neugier wird ausgenutzt. Sprich: Phishing spielt für diese Art von Angriffen eine wichtige Rolle.
- Beim Laden oder Anklicken der manipulierten Links oder Websites führt der Browser des Opfers einen HTTP Request aus, ohne dass das Opfer etwas davon merkt.
Zwei relativ einfache Beispiele verdeutlichen die Funktionsweise einer solchen Attacke.
Gehen wir dafür einmal davon aus, Justus möchte Bob über die Website www.bank.de 100 € überweisen, und Skinny sitzt auf der Lauer, um einen CSRF Angriff durchzuführen. Skinny kann für seinen Angriff die GET- oder die POST-Methode nutzen.
Die nachfolgenden Beispiele stammen übrigens aus folgenden Quellen:
- „Cross Site Request Forgery (CSRF)“ – der Übersichtsartikel der OWASP
- “Preventing CSRF Attacks In WordPress Using Nonces” – von qnimate.com
Cross Site Request Forgery bei der GET Methode
Mit der GET Methode wird eine Ressource von einem Server angefordert, zum Beispiel eine HTML Datei. Die erforderlichen Parameter für den Aufruf werden dabei einfach an die URL angefügt. Und wie wir schon von SQL Injections wissen: Eine URL ist relativ einfach zu manipulieren.
Justus loggt sich also bei www.bank.de ein und gibt alle erforderlichen Daten ein. An den Server würde dabei folgender (völlig fiktiver) Input übermittelt:
GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1Skinny konstruiert jetzt eine URL, die stattdessen 100.000 € auf sein eigenes Konto überträgt. Sie sieht folgendermaßen aus:
http://bank.de/transfer.do?acct=SKINNY&betrag=100000Natürlich muss Justus die Aktion, die sich hinter dem gefälschten Link versteckt, auch ausführen. Deshalb schickt Skinny Justus eine Mail mit einem gefälschten Link zu. Der HTML Code kann z.B. so aussehen:
<a href="http://bank.de/transfer.do?acct=SKINNY&betrag=100000">Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!</a>Oder er schickt ihm eine E-Mail, die ein „unsichtbares“ (weil 0 mal 0 Pixel großes) Bild enthält. Bei dem Versuch, das Bild zu laden, greift der Browser auf die URL zu, ohne dass Justus das überhaupt merkt:
<img src="http://bank.de/transfer.do?acct=SKINNY&betrag=100000" width="0" height="0" border="0">Wenn Justus den Link aufruft – bewusst oder unbewusst –, werden die Parameter an den Server übergeben, die Überweisung ausgelöst und schon verschwinden 100.000 € von seinem Konto.
Natürlich muss Justus auf den Link klicken, während er eingeloggt ist. Wenn sich aber unglücklicherweise in seinem Browser ein Login-Cookie seiner Bank befindet, funktioniert der Angriff auch dann, wenn er die Website gerade nicht geöffnet hat.
Genau das macht Cross Site Request Forgery auch so hinterhältig: Justus ist sich wahrscheinlich gar nicht bewusst, dass das Cookie existiert.
Cross Site Request Forgery bei der POST Methode
Die GET Methode kann in Links verwendet werden und ist somit besonders einfach zu verbreiten. Nun können Anbieter aber dafür sorgen, dass GET Anfragen prinzipiell keine Schreibberechtigung erhalten.
Bleibt noch die POST Methode: Hierbei werden Daten an einen Server übergeben, damit er sie weiterverarbeiten kann. Die Daten sind dabei aber nicht Bestandteil der URL, sondern werden an den Header angehängt.
Klingt vielleicht etwas sperrig, den Anwendungsfall kennst du aber sicherlich, denn Formulare funktionieren auf diese Weise.
Für unseren Angreifer Skinny heißt das, dass er sich zwar mehr Mühe machen muss, aber immer noch ans Ziel kommen kann.
Gleiches Szenario: Justus will Bob Geld überweisen. Er füllt also auf www.bank.de folgendes Formular aus:
<form method="POST" action="geld_ueberweisen.php">
<input type="text" name="von">
<input type="text" name="an">
<input type="text" name="betrag_in_euro">
<input type="submit">
</form>Das schickt den Befehl geld_ueberweisen.php ab, der so aussieht:
if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))
{
transMoney("von", "an", "betrag");
echo "Überweisung erfolgreich!";
}Wie du siehst, prüft der Code anhand des Cookies zunächst, ob Justus eingeloggt ist. Nur dann wird die Überweisung ausgeführt.
Skinny hinterlegt jetzt auf einer manipulierten Website ein unsichtbares Formular, zum Beispiel:
<form method="POST" action="http://www.bank.de/geld_ueberweisen.php">
<input type="text" name="von" value="Justus" style="display: hidden">
<input type="text" name="an" value="Skinny" style="display: hidden">
<input type="text" name="betrag_in_euro" value="100000" style="display: hidden">
<input type="submit" value="Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!">
</form>Den Link zu dieser manipulierten Website schickt er Justus. Der fühlt sich herausgefordert, klickt auf den Button, um das Rätsel zu sehen – und schon führt er unwissentlich die Funktion geld_ueberweisen.php aus. Da diese ein entsprechendes Cookie in seinem Browser findet, werden wieder 100.000 € an Skinny überwiesen.
Angriff über Umwege
Deswegen übrigens auch der Name Cross Site Request Forgery: Der Befehl wird meist von einer anderen Website aus abgeschickt. Um Website A anzugreifen, hinterlegt er also auf Website B schadhaften Code. Dann lockt er das nichtsahnende Opfer hierhin, damit dessen Browser den Code ausführt.
„*“ zeigt erforderliche Felder an
So sicherst du dich gegen CSRF Angriffe ab
Die gute Nachricht: Cross Site Request Forgery ist schon seit Ewigkeiten bekannt. Das Risiko ist bekannt und bei der Entwicklung wird gezielt daran gearbeitet, es aus der Welt zu schaffen.
Die schlechte Nachricht: Du selber kannst dich auf technischer Seite eigentlich nicht dagegen absichern. Der WordPress Core ist inzwischen relativ gut geschützt, und wie man an den laufenden Updates sieht, wird konstant daran gearbeitet. Wie bei anderen Angriffsarten auch, kommen die meisten Schwachstellen durch Plugins daher. Du musst also darauf vertrauen, dass bei der Entwicklung der Erweiterungen, die du benutzt, ein guter Job gemacht wird.
Das heißt konkret:
- Installiere nicht zu viele Plugins und nur die Plugins, die du wirklich brauchst
- Pass auf bei Plugins, die schon seit geraumer Zeit nicht mehr aktualisiert wurden. Hier können sich unbehobene Sicherheitslücken verbergen.
- Informiere dich vorher über die Plugins, die du installierst, zum Beispiel über ihre Kompatibilität mit anderen Plugins oder der WordPress Version, die du benutzt (damit sich das Plugin auch updaten lässt).
- Update deine Plugins und den WordPress Core regelmäßig. Denn die kontinuierlichen Updates sind genau dafür da, um solche Sicherheitslücken zu schließen.
- Sei kritisch in Bezug auf Phishing.
- Wenn du dir unsicher bist: Schau dir das Plugin im WP Repository einmal ganz genau an. Wie fallen die Bewertungen aus, was waren die größten Probleme in der Vergangenheit und hat das Plugin unter Umständen eine prominente Sicherheitslücke nicht geschlossen?
Fazit: CSRF ist ein alter Hut
Cross Site Request Forgery gibt es quasi schon seit Anbeginn des digitalen Zeitalters. Zudem sind die Fallzahlen im Vergleich zu Brute Force Attacken extrem klein.
Das bestätigt auch die Einschätzung der OWASP: Hier geht man davon aus, dass der Angriff eher gering verbreitet, leicht festzustellen und nur in ganz bestimmten Fällen schwerwiegend ist.
Trotzdem ist es gut zu wissen, wie die Attacken funktionieren. Denn häufig klappen die Attacken nur dank menschlicher Fehler. Immer wieder öffnen User aus Neugier Mails oder klicken auf Links, die sie besser nicht geöffnet hätten.
Vor Cross Site Request Forgery schützt du dich also am besten mit Recherche und etwas gesundem Menschenverstand.
