Cross-Site Request Forgery

Betreibt man eine gut besuchte Webseite, so kommt man nicht umhin, sich mit dem Thema Sicherheit auseinander zu setzen. Dabei fallen den Meisten Dinge wie SQL-Injection oder Cross-Site Scripting (XSS) ein und so ging es auch mir. Eine Seite dagegen zu sichern, ist scheinbar nicht weiter schwer, muss man doch „nur“ alle Daten, die in irgendeiner Art und Weise von einem Nutzer kommen, validieren oder maskieren. Cross-Site Request Forgery (CSRF) aber ist eine Angriffsvariante, der man nicht gar so einfach Herr werden kann.

Das besondere an CSRF ist, dass schädlicher Code auf jeder beliebigen Seite auftauchen kann und nicht nur auf der Seite, die angegriffen wird (gut, eigentlich wird nicht die Webseite, sonder der Nutzer angegriffen). Das macht es auch schwieriger, sich dagegen zu schützen. Betrachten wir ein einfaches Beispiel: Jemand hat einen Account auf der Seite www.example.net und ist dort angemeldet. Die Seite hat einen Session-Key oder die Anmeldedaten in Cookies hinterlegt, so dass man angemeldet ist, wenn man die Seite betritt. Um auszuloggen, muss man auf einen Link „Logout“ klicken, der zu www.example.net/logout führt. Wenn unser „Opfer“ jetzt eine andere Seite aufruft, bei der ein Bild folgendermaßen eingebunden ist: <img src="www.example.net/logout" />, so würde es ausgeloggt werden – ohne eigenes zutun.

Wieso ist das so? Der Browser erkennt, dass das Bild (oder sonstwas) von einer bestimmten URL geladen werden soll und schickt, wie bei jedem Request, die Cookies dieser Domain mit. Die Webseite erkennt diese, identifiziert dadurch scheinbar den Nutzer, obwohl in Wirklichkeit nur der Browser identifiziert wird und führt die mit der URL verbundene Aktion aus. So einfach ist CSRF. Das Kernproblem ist hier also, dass die Webseite www.example.net nicht verifizieren kann, ob der Nutzer den Request tatsächlich authorisiert hat, oder ob er anderweitig von dessen Browser gesendet wurde.

Alle Aktionen, die mit einem simplen GET-Request ausgeführt werden können, benötigen also noch nicht einmal JavaScript, um gefährdet zu sein. Wird eine Aktion über ein Formular mittels POST-Request ausgeführt, so muss ein Angreifer JavaScript verwenden – da die meisten Internetnutzer dieses aktiviert haben, ist es auch kein Problem, derartige Aktionen im Namen des Nutzers auszuführen. Dass von diesem Problem auch viele populäre Seiten betroffen sind, zeigt eine Ausarbeitung von Bill Zeller und Ed Felten. In einem Blog-Eintrag sprechen sie unter anderem über YouTube, wo so ziemlich alles anfällig war, aber auch über eine Bank, wo es durch CSRF möglich war, Geld vom Opfer auf sein eigenes Konto zu transferieren. Eine genaue Erläuterung der Angriffe findet sich in einer Ausarbeitung, die besprochenen Sicherheitslücken wurden inzwischen geschlossen.

Die Lösung, die die beiden für Webseitenbetreiber vorschlagen, sieht es erstmal vor, dass Aktionen, die potenziell Daten verändern können, immer über einen POST-Request behandelt werden sollen. Dafür sind also Formulare vonnöten. Zu Beginn jeder Session wird eine Pseudo-Zufallszahl in einem Cookie gespeichert und in jedem Formular sollte sich ein Gegenstück dazu finden. Dieses versteckte Feld wird von einem JavaScript befüllt, das das Cookie ausliest. Der Browser schickt beim Absenden des Formulars das versteckte Feld und das Cookie zum Server, wo dann beide Werte miteinander verglichen werden. Stimmen sie überein, so ist die Anfrage korrekt, anderenfalls nicht.

Das Geheimnis dahinter ist es, dass die Cookies einer Seite nur dann per JavaScript ausgelesen werden können, wenn das JavaScript unter dieser Domain läuft (Same-Origin Policy). Würde das Formular von einer anderen Seite aus abgesendet werden, so könnte das Cookie nicht ausgelesen werden und der Angriff wäre damit unwirksam. Der große Nachteil ist allerdings, das Nutzer mit deaktiviertem JavaScript in die Röhre gucken. Es ist sogar ein wenig ironisch, dass gerade Cookies und JavaScript in diesem Fall für Sicherheit sorgen, sind es doch diese beiden Technologien, die Angriffe wie XSS und CRSF erst ermöglichen. Vorteil dieser Lösung gegenüber anderen ist es, dass es kein Problem mit dem browsen in mehreren Tabs oder Timeouts gibt, wie es z.B. dann der Fall wäre, wenn pro Formular ein eigener zeitlich begrenzt gültiger Zufallswert generiert würde.

Cross-Site Request Forgery Angriffe erscheinen teilweise recht primitiv, aber dafür sind sie umso wirkungsvoller. Gerade bei einfachen GET-Requests hilft auch kein deaktiviertes JavaScript und jedes Bild könnte eine ungewollte Aktion auf einer beliebigen Seite auslösen. Ein solcher Angriff ist auch recht einfach ausgeführt, denn in Foren und ähnlichem kann man in der Regel problemlos Bilder einbinden und je stärker das Forum frequentiert ist, desto mehr Personen tappen in die Falle und merken noch es noch nicht einmal. Umso mehr müssen sich Webseitenbetreiber dieser Gefahr bewusst werden und sich Lösungen überlegen, auch wenn es sicher nie 100%igen Schutz geben kann.

Tags: ,

1 Pingback

  1. Internetsperren - rattlab.net 25. April 2009 um 18:51

Keine Antworten

Die Kommentfunktion ist nicht aktiviert.