Omc Logo
Fallbeispiel zu Cross Site Request Forgery

Fallbeispiel zu Cross Site Request Forgery

Öffentlich
Es sind noch 0 von None Plätzen verfügbar.

Hacker achten bei ihren Angriffen sehr darauf, dass sie kaum Spuren hinterlassen. Eine XSRF-Attacke (Cross-Site Request Forgery, XSRF oder auch, CSRF) ermöglicht genau das. Sie ist u. a. auch als One-Click Attacke bekannt.

Eine One-Click Attacke besteht, wenn ein völlig ahnungsloser Webnutzer dazu veranlasst wird, auf einen Link zu einer unbekannten Webseite zu klicken. Auf der aufgerufenen Webseite wird dem Nutzer nichts Verdächtiges auffallen, sondern eine ihm vermeintlich harmlose Webseite präsentiert. Der Schaden bei einer One-Click Attacke richtet sich nicht gegen den Webnutzer an sich, sondern eher gegen wohlbekannte Webseiten, auf die es der Hacker in Wahrheit abgesehen hat.

Wie ist das gemeint?
In den Niederlanden und in Mexiko wurden spezielle Fälle von XSRF-Attacken bekannt. In den Niederlanden war ein Onlinebanking-Dienst anfällig für XSRF-Attacken. Durch diese XSRF-Anfälligkeit war das Onlinebanking-System verwundbar und so wurden im Auftrag von betroffenen Bankkunden Überweisungen ausgeführt und neue Bankkonten eröffnet, obwohl die Opfer selbst diese nie persönlich in Auftrag gegeben haben.

Vor allem ausländische Banken verwenden keine TAN-Abfrage bei der Authentifizierung von Transaktionen, obwohl diese das CSRF-Risiko minimieren würden. Auf diese Weise konnte sich ein schadhaft, verlinktes Bild, das sich in einer vertrauensvoll aussehenden Webseite (der Bank) versteckt, auf dem eigenen Konto einen riesigen Überziehungszins nach sich ziehen. Genau deshalb ist eine CSRF-Attacke auch als One-Click Attacke bekannt. Ein Klick und schon bewegt sich das Unglücksrad.

Anfang 2008 wurden Kunden einer mexikanischen Bank ebenfalls Opfer einer speziellen XSRF-Attacke. Der Angreifer konnte sich in der Web-Applikation als vertrauenswürdiger/eingeloggter Benutzer bewegen. Dann führt der Angreifer im Namen des Betroffenen gefälschte Anfragen aus, weil der Web-Server einem vermeintlich authentifizierten Benutzer vertraut. Dabei bekommen die Benutzer von diesem Missbrauch nichts mit.

Grundsätzlich sind nicht nur Router anfällig für CSRF-Attacken, sondern v. a. alle Anwendungen mit einer Weboberfläche, also auch Content-Management-Systeme oder Webportale. Dort ist die Wahrscheinlichkeit nämlich höher, dass ein Nutzer gerade in einer Anwendung (z. B. Ebay) eingeloggt und damit authentifiziert ist, während er in einem zweiten Fenster vielleicht etwas bei Google sucht und dabei auf einer manipulierten Webseite landet. Das Problem daran besteht eben nun, wenn der eingeloggte Nutzer auf einer manipulierten Webseite landet und an ihm eine CSRF-Attacke angewandt wird und seine Authentifizierung gegenüber einer Anwendung von einem Hacker missbraucht wird.
So war 2006 die Netflix-Webseite (US-amerikanisches Unternehmen, das sich mit dem Verleih und der Produktion von Filmen und Serien beschäftigt) ebenfalls für CSRF-Attacken anfällig. Hier veränderten Angreifer z. B. die Versandadresse, fügten DVDs in eine Warteschlange ein oder änderten die Anmeldeinformationen, um den Account vollständig auszuspähen oder zu manipulieren.
Selbst McAfee, ein US-amerikanischer Hersteller von Antivirus-, Netzwerk-, Sicherheitssoftware und –hardware, war ebenso anfällig gegenüber CSRF-Attacken, was den Angreifern erlaubte, deren Unternehmenssystem zu verändern.
Ebenso blieb Google Gmail nicht von einer CSRF-Attacke verschont. Ihre CSRF-Schwachstelle wurde 2007 bekannt. Wenn ein Nutzer in seinem Google Account eingeloggt war (vllt. In seinem E-Mail-Account oder seiner persönlichen Homepage), konnte jemand Drittes, unter der Identität des Nutzers, auf dessen Kontaktliste zugreifen. Die Schwachstelle befand sich bei Google darin, dass eine Callback-Funktion ausgeführt wurde und nachdem geprüft wurde, ob ein gültiger Nutzer-Cookie vorlag, die Kontaktliste des Nutzers als Parameter ausgegeben. Was allerdings nicht überprüft wurde, war, von welcher Seite die Anfrage kam. Deshalb wurde letztlich die Anfrage eines unberechtigten Nutzers (dem Hacker) beantwortet, da ja ein eingeloggter Nutzer und somit ein gültiger Nutzer-Cookie vorlag.

Allerdings können nicht nur Browser angegriffen werden. Bösartige Skriptbefehle können überall da eingeschleust werden, wo die Einbindung von Skript-Kommandos ermöglicht wird, wie z. B. in Word-Dokumenten, Flash-Dateien, RSS Feeds u. a.

Watch-Party

Session wird geladen ...

Viewer: 0