Wie funktioniert CSRF? Verständnisproblem.

[Auge]

Hallo

CSRF-Token ... Was macht der? Wie funktioniert der?

Der stellt sicher, dass das Formular vom Server und nicht von anderswo kommt. Der Token wird vom Server generiert und als Hidden-Input ausgeliefert. In der Antwort wird der Wert mit dem gespeicherten verglichen.

Soweit, so (vorher schon) klar.

Wenn nun jemand das Formular fälscht, hat er kein valides Token und die Verarbeitung wird abgelehnt.

Ich habe wohl gedanklich dieses mit anderen Szenarien, in denen der Angreifer z.B. durch Übernahme einer Session selbst direkt in die Anwendung eindringt, verwechselt. Hier geht es nur darum, sicherzustellen, dass die Eingaben direkt aus dem an den angemeldeten Benutzer gesendeten HTML-Formular und nirgendwoanders her stammen. Ist das so korrekt?

1. Im gezeigten Originalcode sind das Ausführungszeichen und das Größer-Als-Zeichen, welche die Emailadresse und das input-Tag abschließen, als maskierte Zeichen notiert.
   • Sollten sie damit nicht ungefährlich sein?
   • Kann es sein, dass die Maskierungen aus dem Test des Fehlermelders stammen, aber der Angriffscode so, wie in meiner Auflösung notiert, unmaskiert sein müsste?

… Wenn die Lücke Wirkung zeigen soll, muss jedenfalls die dekodierte Variante an den Browser geschickt werden, damit der als Code interpretiert, was der Autor, der die potentielle Lücke nicht beachtet hat, dachte es sei Text.

Ich bin zwar nicht der Hauptentwickler, gehe aber davon aus, dass aus Eingaben stammende Daten bei deren Ausgabe samt und sonders maskiert werden. Ich werde mich dennoch durch den Code, der die Eingaben prüft und den, der die Ausgaben generiert, hangeln.

2. Wenn die Emailadresse serverseitig validiert wird, ist ja nach „.comle3d4“ Schluss. Wem wird das Alert untergeschoben? Wird es denjenigen untergeschoben, die sich den betroffenen, bereits gespeicherten Datensatz anschauen, falls die Eingaben nicht mit htmlspecialchars behandelt werden oder lauert da noch an anderer Stelle Ungemach?

Ziel ist es, den Browser Code ausführen zu lassen, in der Regel Javascript-Code, wenn das Opfer auf einen Link klickt. Der Link mit Daten im Anhang wird zum Server gesendet, der erzeugt eine Webseite und baut die Eingabe unmaskiert ein.

Wie gesagt, ich gehe davon aus, dass keine unmaskierte Ausgabe erfolgt ^[1]. Das war auch der Grund, warum ich die Form der Meldung nicht verstehe. Wenn eine unbehandelte Ausgabe erfolgen sollte, würde ich die Meldung genau dieses Fehlers erwarten. Wenn hingegen der durch Eingaben eingeschleuste Code bei sämtlichen Ausgabe entschärft wird und somit seine Wirkung nicht entfalten kann, liegt mMn kein Fehler vor. Eine Fehlermeldung zum rätselraten finde ich jedenfalls befremdlich.

Lücke Numero 3 betrifft CSS-Injektion über den relativ angegebenen Pfad zur CSS-Ressource im Link-Element des Dokumentkopfes. Diesen Umstand zu beheben und daraus eine absolute URL zu machen, ist einfach. Ich verstehe aber leider den Angriffsvektor nicht.

PathInfo - /das/ist/die/url.php/aber/da/hängt/noch/was/dran

Der Browser weiß ja nicht, dass das Dokument, in dem das CSS relativ verlinkt ist, url.php heißt, und so fordert er eben nicht /das/ist/die/datei.css, sondern /das/ist/die/url.php/aber/da/hängt/noch/was/datei.css an. Wenn dabei das URL-Rewriting mitspielt, bekommt man vielleicht sogar eine real existierende Datei ausgeliefert.

Mit einer vollständigen, absoluten URL, z.B. mit //www.example.com/data/default.css, sollte sich das beheben lassen.

Wie kann mir jemand externe CSS-Ressourcen unterschieben, bloß, weil der originale Aufruf mit einer relativen Pfadangabe erfolgt?

Du beschreibst Lücke #3 nicht ausführlich genug. War da wirklich von externen CSS-Ressourcen die Rede? Die müssten ja dann ähnlich zu #1 eingebunden werden.

Wer ist das Ziel des JavaScript-Codes, wenn dieser bei der serverseitigen Verarbeitung der Eingaben nicht gefunden und zurückgewiesen wird?

Der Browser des Opfers. Kontextgerechte Maskierung reicht schon, um einen solchen Angriff wirkungslos verpuffen zu lassen.

Danke für die Klarstellung.

Irgendeine Intelligenz, die schädlichen Code erkennt, braucht man da nicht. Falls eine solche überhaupt in der Lage ist, alle gefährlichen Situationen zu erkennen.

Dass das nur ungenügend und mit der Gefahr unerwünschter Nebenwirkungen funktioniert, ist mir klar. Ich werde den HTML-Teil auf HTML5 und damit die Formularfelder auf die damit eingeführten Typen umstellen, um im Browser Vorprüfungen durchzuführen, aber gegen Angriffe mit gefakten Formularen hilft das auch nicht. Die dafür bestimmten Änderungen sind jedoch von anderer Seite in Arbeit. :-)

Und was bleibt von diesem Angriff übrig, wenn die serverseitige Validierung funktioniert?

… ich würde die Anwendung so schreiben, dass sie nur die Gültigkeit von Eingaben gemäß ihrem eigenen Bedarf prüft. Angriffe herausfiltern würde ich nur dann, um die Handarbeit des Entfernens von Spam- und Unsinns-Einträgen zu sparen/minimieren. Gegen schädliche Wirkung hilft kontextgerechte Maskierung, die man ja auch für gutartige Daten braucht. Kontextgerechte Maskierung ist nicht nur eine Abwehrmaßnahme sondern vor allem für die ordnungsgemäße Arbeit des eigentlichen Programms notwendig. Das Ins-Leere-Laufen von XSS-Angriffen ist dann nur noch ein Nebeneffekt.

Ja, so sehe ich das auch. Ich wollte nur sicherstellen, dass ich wegen meiner Unkenntnis nicht irgendwelchen Voodoo übersehe und wir uns, auf halbem Wege stehenbleibend, in falscher Sicherheit wiegen.

Danke auch an dich.

Tschö, Auge

---

1. Wie ebenfalls gesagt, prüfe ich das noch einmal. ↩︎