Session Token

[MichiLee]

Hi,
vielen Dank für deine ausführliche Antwort. Kein Thema, ich reagiere auch etwas mühsam.
Die Sachen, die ich verstanden habe, habe ich weggenommen. Danke nochmals.

Ich hab jetzt keine Zeit, das Tutorial durchzuarbeiten und weiß nicht, was Du mit "zwei JSP-Seiten erzeugen" meinst. Aber wenn Du einen definierten Input (in Form von einem bestimmten Pfad und den HTTP GET / POST Parametern) zum Aufbau eines Informationsergebnisses per JSP (also das erzeugen des HTML Markups) verwendest, dann erhältst Du bei gleichen Eingaben in der Regel gleiche Ausgaben (Voraussetzung: der Datenbestand ändert sich nicht und es werden keine pseudozufälligen Prozesse verwendet). Es kommt also nur darauf an, dass der Anwender den selben Pfad mit den selben Eingabeparametern (GET oder POST) verwendet, um bei zwei Requests die selbe Response zu erhalten. Bei Verwendung eines Tokens wird das explizit unterbunden, weil sich der Datenbestand (in der Session) geändert hat und dafür sorgt, dass ein erneuter Aufruf einen Fehler produziert.

genau. Man kann zwar identische Response erzeugen, man hätte aber zwei verschiedene Tokens. Laut dem Tutorial soll es aber möglich sein, zwei identische Tokens zu erzeugen, was mir nicht klar ist. Aber nicht so wild.
Ist auch nicht wirklich ein wichtiges Thema. Vielleicht schreibe ich mal den Verfasser direkt an, wie er es meint.

Wie in etwa läuft dann Session-Hijacking.
Ein Hacker X schleust in meinen Server, bzw. in den Code (Bsp. Gästebücher) Javascript-Code, wo er von einem Benutzer/Client, der grad die Seite besucht per document.cookie die Session-ID ausliest und klaut.

Exakt. Das ist auch der Grund dafür, in Servlet 3.0 endlich HTTPonly Cookies anzubieten, die nicht mit Javascript ausgelesen werden dürfen.

Das hört sich gut an.

Was genau hat dies aber mit dem img-tag an sich? Wenn der Hacker X ein img-tag mit einem fremdbild von seinem eigenen Server lädt, wie transportiert er hier nun die Session-ID, geschweige liest er sie vom Client aus?

Dazu muss auf Serverseite beim Angreifer einfach kein Bild hinterlegt sein, sondern eine dynamische Komponente (der Einfachheit halber einfach mal ein Servlet, um beim Thema zu bleiben) lauschen, die aus der URL die interessanten Informationen ausliest. Auf die selbe Art und Weise funktionieren die meisten Click Tracking Systeme. Die Bild-URL ist nur eine Möglichkeit, einen Request abzusenden, den der Browser "automatisch", d.h. ohne Userinteraktion macht.

Ob ich das richtig verstanden habe:
Hacker X kann wie oben erwähnt javascript auf meinen Server oder Webseite einschleusen und damit direkt auslesen. (bis HTTPonly erscheint) Das wäre die Möglichkeit eins.

Die zweite unabhängige Möglichkeit wäre es, dass der Hacker X ein img-tag mei mir auf dem Server einbaut (bsp. Foren, Gästebucher...)
In dem IMG-Tag ist ein normaler Pfad auf den Server des Hackers angegeben.

1. Dies kann ein Bildpfad sein auf meinem Server, auf dem Server sitzt aber hinter dme Bildpfad ein Servlet? (möglich, servlets, bzw. jsp's umzubennenen? Dieses Servlet liest dann von meiner URL (Anfrage-URL auf meinen Server) meine Session-ID (falls überhaupt per URL-Rewriting auf die URL angewendet)

2. Falls kein URL-Rewriting angewendet, könnte er mit dem Servlet nicht viel auslesen oder?

3. Jetzt kommt die Sicherheitsvorkehrung von URL-Rewriting ins Spiel, dass nur auf den Ursprungsserver (besser ContextPath) angewendet wird. Diese Sicherheitsvorkehrung bringt jedoch im Falle vom img-tag nichts, da ich ja den Ursprungsserver angeprochen habe eigentlich und da innerhalb ein img-tag (ein Request auf den Servers des Hackers) ausgelöst wurde)

Grüße