Session Token

[pgoetz]

Guten Morgen,

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

Wahrscheinlich ist das das beste. Ich kann mir gerade nicht vorstellen, was gemeint ist.

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

Genau. Beide Angriffsszenarien funktionieren in der Regel dann, wenn der Benutzer GET- oder POST-Parameter manipuliert, und diese ungeprüft gelesen und wieder ausgegeben werden. Klassiker: das Suchfeld, bei dem man die Benutzereingabe wieder ausgibt (ungeprüft und unverändert). Hier kann ich mit einem kleinen Javascript-Schnipsel etwas beim Client tun.

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)

Du kannst ein Servlet ja auf jedes mögliche URL-Pattern lauschen lassen, z.B. *.gif. Das ist in der web.xml angegeben. Bei einer JSP ist das wieder nicht so einfach, da muss schon ein Controller-Servlet davorhängen.

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

Genau. Er würde höchstens noch die Standarddaten des Benutzers über den HTTP Header erhalten und wissen, dass geklickt wurde. Weiterer Inhalt kann nicht transportiert werden, außer Teil der img-src ist ein Fitzelchen Javascript, was wiederum Daten aus z.B. einem Cookie selbst auslesen kann. Dann wird die img-src nicht von Dir auf dem Server umgeschrieben, sondern vom Client mit Javascript.

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)

Nö, wenn Dein Server folgender ist: goodboy.invalid, und der Hackerserver badboy.invalid hat, dann zeigt das Bild, das der Angreifer über einen Parameter in Deine Anwendung geschleust hat, ja auf http://badboy.invalid/evil/image.gif. Wenn jetzt Deine Anwendung bei fehlender Transportmöglichkeit der SessionID in einem Cookie die URLs verändert (auch diejenigen, die aus Deiner Anwendung rauszeigen), dann würde der Angreifer die SessionID des aktuellen Benutzers über die Query-Parameter (GET) erhalten.

Schöne Grüße,

Peter