CSRF, dieses Kürzel taucht immer wieder in den Sicherheits- und Wartungsupdates des WordPress-Core auf. Die Methode, die dahintersteckt, ist mittlerweile ein alter Hut und nutzt die reichlich vorhandenen Cookies eines Internetnutzers 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 Seite verlassen hast. Besuchst du die Seite dann erneut, musst du deine Login-Daten nicht noch einmal eingeben, sondern wirst direkt eingeloggt. Für den User ist das natürlich super, weil es – genau wie eine Passwortverwaltung oder ein sog. Single Sign On – lästiges Formularausfüllen spart.
Im Hintergrund läuft dabei folgendes ab: Wenn du dich zum ersten Mal auf der Seite einloggst, hinterlegt die Webseite 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 Zeichen-String.
Bei deinem nächsten Besuch auf der Webseite überprüft der Server diesen Zeichen-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.
Eine CSRF-Attacke ist im Kern Vertrauensmissbrauch
Du merkst schon: Bei einer entsprechenden Attacke gaukelt der Angreifer dem Dienst, der die Cookies ausliest etwas vor. Wie genau das passiert, erkläre ich weiter unten an zwei Beispielen.
Die Gefahr dieser Manipulation liegt darin, dass ein Dritter, also der Angreifer, bspw. 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 bspw. 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 Web-Anwendungen heraus. Auf der vorläufigen Liste für 2017 besetzt CSRF Platz 8 von 10. 2007 und 2010 landete die Attacke noch auf Platz 5, 2013 stieg sie auf Platz 8 ab.
Das liegt wohl unter anderem daran, dass CSRF-Attacken beinah 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 bspw. 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 Plugin- und Applikationsentwickler relevant, als für Webdesigner, Agenturen und KMUs. Denn der Schutz vor CSRF ist auch eine Frage der Programmierung. Relevant könnte CSRF bspw. 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:
- Der Hacker bringt das Opfer dazu, eine manipulierte Seite zu laden oder auf einen Link zu klicken, zum Beispiel indem er sich als eine Vertrauensperson ausgibt oder die menschliche Neugier ausnutzt. Sprich: Phishing spielt für diese Art von Angriffen eine wichtige Rolle.
- Beim Laden oder Anklicken der manipulierten Links oder Seiten 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 Seite www.bank.de 100€ überweisen, und Skinny sitzt auf der Lauer, um einen CSRF-Angriff durchzuführen. Skinny kann für seinen Angriff nun bspw. 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.1
Skinny 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=100000
Natü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 Email, 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 Seite gerade nicht geöffnet hat.
Genau das macht Cross-Site Request Forgery auch so hinterhältig: Der Geschädigte ist sich unter Umständen 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. Das spielt dem Angreifer in Sachen Distribution natürlich in die Hände. 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 funktioniert 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 erstmal, ob Justus eingeloggt ist. Nur wenn es so ist, wird die Überweisung ausgeführt.
Skinny hinterlegt jetzt auf einer manipulierten Webseite ein unsichtbares Formular, z. B.
<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 Webseite 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 Hacker schickt den Befehl meist von einer anderen Seite aus ab. Um Seite A anzugreifen, hinterlegt er also auf Seite B schadhaften Code. Dann lockt er den nichtsahnenden User hierhin, damit dessen Browser den Code ausführt.
So sicherst du dich gegen CSRF-Angriffe ab
Die gute Nachricht: Cross-Site Request Forgery ist schon seit Ewigkeiten bekannt. Entwickler kennen das Risiko und arbeiten gezielt daran, 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 mit Plugins daher. Du musst also darauf vertrauen, dass die Entwickler der Erweiterungen, die du benutzt, einen guten Job machen.
Das heißt konkret:
- Installier‘ nicht zu viele Plugins und nur die Plugins, die du wirklich brauchst
- Pass’ auf bei Plugins, die von den Entwicklern schon seit geraumer Zeit nicht mehr aktualisiert wurden. Hier können sich unbehobene Sicherheitslücken verbergen.
- Informier’ dich vorher über die Plugins, die du installierst, z. B. ü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 WP-Core regelmäßig. Denn die kontinuierlichen Updates sind genau dafür da, um solche Sicherheitslücken zu schließen.
- Sie 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 u.U. 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 bspw. 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 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.
Egal ob als Nutzer oder Anwender: Vor Cross-Site Request Forgery schützt du dich also am besten mit Recherche und etwas gesunder Menschenverstand.
