Wie funktioniert CSRF? Verständnisproblem.

[dedlfix]

Tach!

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. Wenn nun jemand das Formular fälscht, hat er kein valides Token und die Verarbeitung wird abgelehnt.

Lücke #2

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?

Diese Frage kann ich dir nicht beantworten, weil ich dein Meldungssystem nicht kenne. Mitunter haben Systeme eine gutgemeinte Intelligenz eingebaut und filtern oder machen anderweitig Eingaben kaputt, anstatt sie lediglich kontextgerecht zu maskieren. Lass dir im Zweifelsfall die Daten per Plain-Text-Mail oder als (eingepackte) Textdatei im Anhang schicken. 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.

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. Damit kann man dann prinzipiell alles machen, was der Anwender von sich aus zu machen in der Lage wäre. Z.B. Requests absetzen, während sein Anmeldungs-/Sessioncookie mitgesendet wird.

Lücke #3

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. Inwieweit die dann Unfug anstellen kann, sei mal dhingestellt.

Ich habe leider keine Vorstellung, wie solche Angriffe funktionieren. Wie kommt eine andere Website, die gleichzeitig mit der des Projektes im Browser geöffnet ist, an die Anmeldung in Form des Cookie, wie es die oben verlinkte Wikipedia-Seite und auch der Melder der Lücken beschreiben?

In der anderen Website (oder auch in einer Email) ist ein Link zum Projekt enthalten, den der Anwender klickt. Cookies werden zur URL gespeichert und nicht zu Tabs/Fenstern, so dass auch im der Request im Nachbartab das aktuelle Session-Cookie mitsendet.

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. 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.

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

Validierung ist die Prüfung gegen die Regeln der Geschäftslogik. Ob man damit Angriffe erkennen kann oder nicht, spielt keine Rolle, solange die kontextgerechte Maskierung beachtet wird.

Anders ausgedrückt, 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.

dedlfix.