Wie funktioniert CSRF? Verständnisproblem.

[Auge]

Hallo

In einem Projekt, in das ich involviert bin, wurde (u.A.) eine Cross-Site-Request-Forgery-Sicherheitslücke gemeldet. Die Meldung erfolgte nicht öffentlich und auch nicht an mich, weshalb ich sie hier auch nicht im Wortlaut wiedergeben möchte. Die im Projekt verwendete Sprache ist PHP.

Lücke #1

Sinngemäß heißt es in der Meldung, ein Angreifer könne für einen angemeldeten Benutzer Aktionen mit dessen Account auslösen, wenn der Benutzer gleichzeitig sowohl in einer Installation des Projekts angemeldet ist, als auch eine präparierte Website des Angreifers aufgerufen hat. Als Beispiel wird die Registrierung eines neuen Benutzers und die Ausweitung der Rechte eines Benutzers mit gefälschten Formularen (ginge, wenn es geht, natürlich auch ohne sie) genannt.

Die Anmeldung in einer Installation erfolgt per Formular und es wird bei erfolgreicher Anmeldung eine Session erstellt. Der Session-Name wird per Cookie hin- und hergereicht. Die hiesige Suche zum Begriff CSRF ergibt im Zeitraum der letzten zwei Jahre bisher nur drei Ergebnisse. In einem der Beiträge wird auf einen CSRF-Token verwiesen. Was macht der? Wie funktioniert der?

Es wird auch noch auf zwei weitere Lücken hingewiesen. Ich kann, da ich mir den betreffenden Code noch nicht angeschaut habe, keine Aussage darüber treffen, ob eine oder beide Lücken mit der oben beschriebenen in Zusammenhang stehen.

Lücke #2

Es wird darauf verwiesen, dass zwei Felder eines bestimmten Formulars anfällig für einen „reflected XSS“ seien. Als Beispiel wird folgende Zeile gezeigt …

<input type="hidden" name="email" value="test&#64;example&#46;comle3d4&quot;&gt; &lt;script&gt;alert&#40;1&#41;&lt;&#47;script&gt;"/> 

… die ich in folgenden Code aufgelöst habe.

<input type="hidden" name="email" value="[e-mail]3d4"> <script>alert(1)</script>"/>

Dazu ein paar Fragen.

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

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.

Mir stellen sich folgende Fragen …

… auf deren Beantwortung ich hoffe.

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? Wie kann mir jemand externe CSS-Ressourcen unterschieben, bloß, weil der originale Aufruf mit einer relativen Pfadangabe erfolgt? Wer ist das Ziel des JavaScript-Codes, wenn dieser bei der serverseitigen Verarbeitung der Eingaben nicht gefunden und zurückgewiesen wird? Und was bleibt von diesem Angriff übrig, wenn die serverseitige Validierung funktioniert?

Tschö, Auge