Hi,
da hat schon jemand mit Ja geantwortet für mich :-)
Erstmal folgende Feststellung: Alles was nach dem Login einschließlich Sessionkey SK vom Browser zum Server geschickt wird, um zu prüfen ob die Session ok ist, kann geklaut und nachgebildet werden. Es hat also wenig Sinn, außer dem SK noch den UserAgent (ob IE, Mozi, FF...) oder irgendwelche Daten aus versteckten Formularfeldern zu übertragen.
Hab nach SessionKeys SK mal gegoggelt, aber nichts gefunden. Vom Prinzip her dürfte es doch dasselbe (ähnlich) wie die SessionID Verwaltung vom Webserver sein oder? Entweder schleif man die SessionID über die Adresszeile immer mit oder der Webserver schickt es an den Browser und der Browser speichert es dann als Cookie. Wie auch immer.
Schauen wir mal weiter, was es noch so gibt.
HTTPS (SSL): Gute Idee, die Übertragung ist verschlüsselt, Klau des SK auf dem Ü-Weg nicht möglich.
IP-Adresse: Sofern sich diese nach einem Login nicht ändert, könnte die außer dem SK den Endrechner identifizieren, zumindest für die Dauer einer Session. Sind Proxyserver im Spiel, könnte es sein, dass sich die IP-Adresse noch innerhalb einer Session ändert (round robin-Proxies) oder dass mehrere User mit dergleichen IP-Adresse, nämlich mit der des Proxies vertreten sind. Hier wäre die Variable HTTP_X_FORWARDED_FOR von Interesse, die auf einem Proxy (squid) gesetzt werden sollte und die IP-Adresse des eigentlichen Requesters durchreicht.
Stimmt, an Proxies hatte ich nicht gedacht.
Von unserem Professor habe ich heute auch erfahren, dass ich Loginverfahren niemals selber realisieren soll, sprich Passwörter in DB.s speichern und um die Authentifizierung kümmern, sondern dem Webserver überlassen. (Für Tomcat gäbe es da irgendwelche Security-Einstellungen - Irgendwas mit Rollen)
Grüße
Michi