nicht angemeldet
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