Michilee: Session Token

Hi Forum,
ich habe heute dies durchgelesen:
http://www.jsptutorial.org/content/session#innerLink7

Und bin unten etwas hängengeblieben bei der Erklärung
"
Wie man sieht, wird das Token gleichermaßen in den Request und in die Session gelegt. Warum nicht nur an einer Stelle? In der JSP müssen wir das Token als Bestandteil sämtlicher Links und/oder als Action-Attribut eines Formulars ausgeben. Zum Zeitpunkt der Ausgabe in der JSP kann bereits durch eine parallele Anfrage ein anderes Token als ursprünglich angefordert in der Session abgelegt worden sein könnte. Zwei Seiten würden dann das gleiche Token verwenden - etwas, was unser Token-Handling unnütz machen würde, da Anfragen beider Seiten in der Folge akzeptiert würden. Indes steht auch bei mehreren gleichzeitigen Anfragen für jede Anfrage ein eigenes Request-Objekt zur Verfügung, und somit greift die Ausgabe in der JSP weiterhin auf das korrekte Token zu, wenn sie dieses aus dem Request nimmt.
"

1. Das man an zwei Stellen speichert hört sich gut an, was ich aber nicht verstehe, wenn zwei Seiten geladen würden, warum man zweimal denselben Token erhält?

2. Diese zwei Zeilen habe ich auch nicht ganz verstanden
HttpSession session = getSession(request);
String token = getToken();

getToken(). Man kann eine Methode ohne Punkt aufrufen, wenn sie innerhalb derselben Klasse womöglich ist, wie sieht es jedoch bei getSession oben aus, wobei ich dachte, dass man da als Wert nur false oder true mitgeben konnte, hier jedoch wird ein request mitgegeben und der ganze Methodenaufruf wiederum ohne Punkt davor?

Allgemein Listener und Handler muss ich mir auch noch anschauen. In den Handlern wäre ja der Code von oben drin. Handler praktisch alle JSP-Seiten, die es im Projekt gibt?

3. Ah zwei Kleinigkeiten hätte ich noch:
"
Dafür kann man geeignete Listener implementieren, die entweder bei Erzeugung und Zerstörung einer Session aufgerufen werden (javax.servlet.http.HttpSessionListener), die auf das Hinzufügen und Entfernen von Objekten zu einer Session reagieren
"
Listener reagieren automatisch oder muss man die irgendwie implementieren/aufrufen?

4. Als große Sicherheit bei Session ist ja immer die Rede von "Ursprungsregel". Was meint man damit genau? Wenn ein Client/Anfrager die URL des Servers aufruft und nicht über eine andere Domain aufruft? Habe ich nicht so ganz gecheckt.

Viele Grüße

  1. schönen sonntag euch allen

    niemand nen tipp?

    grüße

  2. Guten Morgen!

    [...]

    1. Das man an zwei Stellen speichert hört sich gut an, was ich aber nicht verstehe, wenn zwei Seiten geladen würden, warum man zweimal denselben Token erhält?

    Ich denke, hier ist es so gemeint, dass zwei Requests, die von der selben Ursprungsseite kommen (User war zu ungeduldig und klickt nochmal oder arbeitet mit Browser Back und Forward), das selbe Token schicken. Wenn dieses Token aber schon mal verarbeitet wurde, darf eine zweite Verarbeitung nicht stattfinden. Dieses Pattern ist in meinen Augen aber nur für wenige Einzelfälle von Bedeutung. In der Mehrzahl der Fälle sollte man seine Seiten so implementieren, dass der Anwender auch mit der Browser Vor- und Zurück-Steuerung arbeiten kann.

    1. Diese zwei Zeilen habe ich auch nicht ganz verstanden
      HttpSession session = getSession(request);
      String token = getToken();

    Beide Methoden müssen innerhalb der Klasse (üblicherweise Servlet) definiert sein, weil sie nicht aus dem Standard API von JSP / Servlets kommen. Häufig kapselt man das ermitteln der Session, wenn man noch zusätzliche Arbeiten an der Session oder beim Ermitteln der Session ausführen möchte, bevor sie der aufrufenden Komponente übergeben (üblicherweise Servlet) wird.

    Allgemein Listener und Handler muss ich mir auch noch anschauen. In den Handlern wäre ja der Code von oben drin. Handler praktisch alle JSP-Seiten, die es im Projekt gibt?

    Das zeugt von schlechtem Stil und lässt mich an dem Tutorial zweifeln. Ein Handler sollte zunächst ein Servlet (oder bei Verwendung eines entsprechenden Frameworks eine Action oder ein Controller) sein. Die JSP ist ausschließlich für die Darstellung der Informationen zuständig und sollte keinen Quellcode enthalten.

    Listener reagieren automatisch oder muss man die irgendwie implementieren/aufrufen?

    Die reagieren "automatisch", wobei das heißt, dass der Servlet Container die entsprechende Listener-Methode aufruft, wenn ein belauschtes Ereignis eingetreten ist. Der Servlet Container sagt also z.B. allen registrierten SessionContextListener-Implementierungen, wenn der ServletContext initialisiert oder zerstört wurde (vom Servlet Container, deshalb kann der auch Bescheid sagen, weil er es weiß).

    1. Als große Sicherheit bei Session ist ja immer die Rede von "Ursprungsregel". Was meint man damit genau? Wenn ein Client/Anfrager die URL des Servers aufruft und nicht über eine andere Domain aufruft? Habe ich nicht so ganz gecheckt.

    Ich kenne jetzt den Begriff "Ursprungsregel" nicht, würde ihn aber sogar ein wenig weiter fassen als nur den Referrer auf eine Domain zu prüfen. In einer komplexen Webanwendung kann der Benutzer bestimmte Seiten nur ein einem definierten Kontext aufrufen (z.B. mehrseitiger Assistent bei einer Benutzerregistrierung). Wenn jetzt ein Request für die dritte Seite ankommt, und der Benutzer kommt nicht von der zweiten, ist das ein Fehler. Wobei hier eine Prüfung nur auf den Referrer nicht ausreicht (weil clientabhängig), hier muss man dann schon als Entwickler ein entsprechendes Token mitgeben.

    Schöne Grüße,

    Peter

    1. Hi,

      Ich denke, hier ist es so gemeint, dass zwei Requests, die von der selben Ursprungsseite kommen (User war zu ungeduldig und klickt nochmal oder arbeitet mit Browser Back und Forward), das selbe Token schicken. Wenn dieses Token aber schon mal verarbeitet wurde, darf eine zweite Verarbeitung nicht stattfinden. Dieses Pattern ist in meinen Augen aber nur für wenige Einzelfälle von Bedeutung. In der Mehrzahl der Fälle sollte man seine Seiten so implementieren, dass der Anwender auch mit der Browser Vor- und Zurück-Steuerung arbeiten kann.

      danke. genau, wenn man zurück geht hätte man ein veraltetes Token. Das ist mir klar. Nicht so ganz klar ist, wie man zwei JSP-Seiten erzeugen kann, wo man zwei "gleiche" Tokens erhält, wie in dem Tutorial beschrieben.

      1. Diese zwei Zeilen habe ich auch nicht ganz verstanden
        HttpSession session = getSession(request);
        String token = getToken();

      Beide Methoden müssen innerhalb der Klasse (üblicherweise Servlet) definiert sein, weil sie nicht aus dem Standard API von JSP / Servlets kommen. Häufig kapselt man das ermitteln der Session, wenn man noch zusätzliche Arbeiten an der Session oder beim Ermitteln der Session ausführen möchte, bevor sie der aufrufenden Komponente übergeben (üblicherweise Servlet) wird.

      Kapseln --> Erben ?

      Normalerweile sollte die Zeile oben ja eher so aussehen:
      HttpSession session = request.getSession(false);
      und nicht
      HttpSession session = getSession(request);

      deshalb frage ich mich, wie man direkt eine Methode ohne xyz aufrufen kann?
      xyz.getSession();

      Das zeugt von schlechtem Stil und lässt mich an dem Tutorial zweifeln. Ein Handler sollte zunächst ein Servlet (oder bei Verwendung eines entsprechenden Frameworks eine Action oder ein Controller) sein. Die JSP ist ausschließlich für die Darstellung der Informationen zuständig und sollte keinen Quellcode enthalten.

      Das stimmt. Auf den ersten Seiten des Tutorials wurde auch erst das MVC erklärt. Vielleicht geht es später auch in die Richtung. Hoffe ich mal, nicht, dass ich ein Dreck lerne :-)

      Die reagieren "automatisch", wobei das heißt, dass der Servlet Container die entsprechende Listener-Methode aufruft, wenn ein belauschtes Ereignis eingetreten ist. Der Servlet Container sagt also z.B. allen registrierten SessionContextListener-Implementierungen, wenn der ServletContext initialisiert oder zerstört wurde (vom Servlet Container, deshalb kann der auch Bescheid sagen, weil er es weiß).

      Oki, bevor ich mich in diesen Bereich mit Fragen vertiefe, schaue ich mir lieber den Bereich nochmal an, da ich noch keine Zeit hatte, mir nochmals das ganze mit Extends, Implements, Abstract usw. anzuschauen.
      In der Antwort steht ja auch SessioContectListener-Implementierungen, wo ich evtl. meine Probleme hätte. Ich schau mir das an und stelle meine Frage dann zielgerichteter. (Wie ich was registriere)

      Kann man in etwa spezifisieren, wer der Servlet-Container ist, da in vielen Tutorials die Rede von Servlet-Container ist, aber nicht wirklich erklärt wurde. Man hat ja eigene JSP's und Servlets. Ist der Container von Tomcat?

      Ich kenne jetzt den Begriff "Ursprungsregel" nicht, würde ihn aber sogar ein wenig weiter fassen als nur den Referrer auf eine Domain zu prüfen. In einer komplexen Webanwendung kann der Benutzer bestimmte Seiten nur ein einem definierten Kontext aufrufen (z.B. mehrseitiger Assistent bei einer Benutzerregistrierung). Wenn jetzt ein Request für die dritte Seite ankommt, und der Benutzer kommt nicht von der zweiten, ist das ein Fehler. Wobei hier eine Prüfung nur auf den Referrer nicht ausreicht (weil clientabhängig), hier muss man dann schon als Entwickler ein entsprechendes Token mitgeben.

      Ich habe mich vertippt, das sollte "Ursprungsserver" heißen. Weiteres Zitat:
      "
      Sendet der Browser ein Cookie mit, so geben sowohl der Tag als auch die beiden encodeURL-Methoden die URL unverändert zurück. D.h. URL-Rewriting wird nur angewendet, wenn der Client kein Cookie sendet. Außerdem achten beide angebotenen Hilfsmittel darauf, dass URL-Rewriting nur bei Links verwendet wird, die wieder gegen den Ursprungsserver gehen. Dies ist eine wichtige Sicherheitsvorkehrung, würde man doch sonst seine Session-Kennung Links beifügen, die diese nicht nur nicht benötigen, sondern besser auch gar nicht haben sollten. Mehr zur Sicherheitsproblematik bei Sessions etwas weiter unten.
      "

      Evtl. habe ich das so verstanden, dass ich auf "meinem" Server auch Links auf externe Server per URL-Rewriting eine Session-ID auf einen externen/fremden Server kodieren kann. Deshalb sollte man URL-Rewriting immer nur auf den Ursprungsserver, also auf meinen Server anwenden?

      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.

      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?

      Viele Grüße
      Der Michi

      1. Servus,

        ich bin diese Woche in einem Seminar und deshalb dauert es ein wenig, bis ich antworte.

        [...]
        danke. genau, wenn man zurück geht hätte man ein veraltetes Token. Das ist mir klar. Nicht so ganz klar ist, wie man zwei JSP-Seiten erzeugen kann, wo man zwei "gleiche" Tokens erhält, wie in dem Tutorial beschrieben.

        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.

        [...]
        Kapseln --> Erben ?

        Normalerweile sollte die Zeile oben ja eher so aussehen:
        HttpSession session = request.getSession(false);
        und nicht
        HttpSession session = getSession(request);

        deshalb frage ich mich, wie man direkt eine Methode ohne xyz aufrufen kann?

        Nein, kapseln heißt einfach, in der Klasse (z.B. Servlet) existiert eine lokale Methode getSession(request), die folgendes macht:
        private HttpSession getSession(HttpServletRequest request) {
            HttpSession result = null;
            // mach ein paar Sachen als Voraussetzung

        result = request.getSession(/* evtl. true | false */);

        // mach ein paar Sachen als Abschluss

        return result;
        }

        [...]
        Kann man in etwa spezifisieren, wer der Servlet-Container ist, da in vielen Tutorials die Rede von Servlet-Container ist, aber nicht wirklich erklärt wurde. Man hat ja eigene JSP's und Servlets. Ist der Container von Tomcat?

        Der Container ist der Tomcat. Ein Servlet Container ist nur die Ablaufumgebung für Servlets. Beispiele sind der Apache Tomcat, Jetty, Resin, ...

        [...]
        "
        Sendet der Browser ein Cookie mit, so geben sowohl der Tag als auch die beiden encodeURL-Methoden die URL unverändert zurück. D.h. URL-Rewriting wird nur angewendet, wenn der Client kein Cookie sendet. Außerdem achten beide angebotenen Hilfsmittel darauf, dass URL-Rewriting nur bei Links verwendet wird, die wieder gegen den Ursprungsserver gehen. Dies ist eine wichtige Sicherheitsvorkehrung, würde man doch sonst seine Session-Kennung Links beifügen, die diese nicht nur nicht benötigen, sondern besser auch gar nicht haben sollten. Mehr zur Sicherheitsproblematik bei Sessions etwas weiter unten.
        "

        Evtl. habe ich das so verstanden, dass ich auf "meinem" Server auch Links auf externe Server per URL-Rewriting eine Session-ID auf einen externen/fremden Server kodieren kann. Deshalb sollte man URL-Rewriting immer nur auf den Ursprungsserver, also auf meinen Server anwenden?

        Ob das Tag das URL Rewriting nur auf Adressen anwendet, die vom Ursprungsserver (besser wäre nur von der aktuellen Anwendung (-> ContextPath), kann ich Dir nicht sagen, da ich das Tag nicht verwende (eine Jakarta Tag Library, die nicht Standard ist?). Aber so sollte das laufen: URL Rewriting nur bei Pfaden, die von der aktuellen Anwendung und damit des aktuellen Session Context kommen.

        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.

        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.

        Schöne Grüße,

        Peter

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

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

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

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

            1. Hi Peter,

              danke dir für deine Mühen.

              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.

              genau. der java-script muss dann, wenn bei mir unverändert eingeschleust und beim client etwas getan hat, bsp den cookie ausgelesen, dann diesen auch irgendwie mir (Dem hacker X) zukommen lassen / zugänglich machen.

              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.

              Ach, stimmt ja. Genau. Dann sich dies auch erledigt. Wie es beim JSP läuft, bzwl. dass es nicht so einfach ist, da ein Controller-Servlet davor muss, habe ich zwar nicht verstanden, schaue ich mir aber bei Gelegenheit an.

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

              oki, meine Anwendung würde praktisch innerhalb der Anwendung auch die URL's verändern, die rauszeigen. Dann erklärt das alles und die Sicherheitsvorkehrung würde wenig bringen.
              Nochmals vielen Dank, die Tage könnte es möglich sein, dass ich mit einem neuen Thread abstract, interfaces usw. nerven könnte, aber davor will ich mir das nochmal anschauen, dass meine Frage erst garnicht auftaucht, bzw. ich dann verständlicher fragen kann.

              viele grüße und ein schönes wochenende eigentlich ab morgen :-)