nicht angemeldet
Na ja, siehe das fiktive Szenario, mehrere Personen in einer WG oder in einem Betrieb am selben Rechner greifen auf dieselbe Site zu ...
Aber die hacken doch nicht alle gleichzeitig auf der Tastatur rum, sondern nacheinander.
Nein, schon richtig, aber die Frage wird interessant, wenn die Sitzung-Cookies dauerhaft abgelegt werden.
Da hast du in der Tat recht.
Die SID hatte ich per URL jeweils weitergereicht. Die SID hatte ich nach einem Zufallsalgorithmus, z. B. aus IP und mt_rand, erstellt und mit md5 verschlüsselt.
Die Anwendung von md5 ist oftmals eigentlich überflüssig. Eine zufällige Ziffernfolge wird nicht dadurch zufälliger, dass sie per md5 quasi "umsortiert" wird, in der Theorie ist es möglicherweise eher andersrum. Kurzum: Man kann's machen, nötig ist es aber nicht.
Was genau legt denn nun PHP im Sitzungs-Cookie ab? Die SID?
Ja.
Noch mehr?
Nein.
Es wäre doch theoretisch möglich, wenn das Sitzungs-Cookie mit Verfallszeit gespeichert wird, daß der User die Cookie-Datei per Editor ändert und, wenn es zutrifft, daß PHP die SID im Cookie speichert, durch Ändern des Cookies eine fremde Sitzung kapert!?
Richtig. Aber nun finde mal eine Kennung, die sich gerade in Benutzung befindet. Bei 32 Stellen à 16 Werte, wie PHP es wohl macht, ergeben sich, wenn ich mich nicht täusche, über eine Quadrillion Möglichkeiten (25-stellige Zahl). Da kannst du (oder der Hacker) lange probieren.
Das Kapern einer Sitzung ist in der Praxis nur vorstellbar, wenn eine Kennung bereits bekannt ist. Das ist dann aber kein Sitzungs-, geschweige denn Cookie-Problem mehr, weil in dem Fall davon auszugehen ist, dass der Bösewicht entweder unterwegs an der Leitung horcht oder sogar bereits im Rechner sitzt, wo er dann neben dem Netzwerkverkehr auch gleich Tastatur- und Mauseingaben des Benutzers mitschreiben kann.
Die einzige Ausnahme: Wer die Kennung als URL-Parameter transportiert, eröffnet bei technisch unerfahrenen Besuchern ein Sicherheitsloch. Es könnte sein, dass so ein Besucher kurzerhand die komplette URL aus der Adressleiste des Browsers kopiert und sie an irgendwen weitergibt, weil er auf der dazugehörigen Seite irgendwas Interessantes entdeckt hat. Deshalb gehört die Sitzungskennung grundsätzlich in ein Cookie und nicht in die URL.
Verstehe ich leider nicht ganz: "Siehe auch session_get_cookie_params() und session_set_cookie_params(). Da das Cookie vom Browser zurückgegeben wird, wird seine Lebensdauer nicht verlängert. Es muss mittels setcookie() gesendet werden."
Vermutlich soll das bedeuten, dass PHP nur unregelmäßig die Cookiedaten zum Browser sendet und man somit nicht nach Belieben die Verfallszeit ändern kann, schon gar nicht irgendwo mitten in der Seite, wenn der HTTP-Kopf, in dem Cookies transportiert werden, schon längst gesendet wurde.
IMHO sollte es reichen, wenn vor session_start() mit session_set_cookie_params() die Parameter eingestellt werden, denn erst mit session_start() wird sich PHP (logischerweise) daran machen, den Cookie zu schicken.
Eine andere Möglichkeit wäre, cookie_lifetime in der Serverkonfiguration zu setzen, zB in Apaches .htaccess mit
php_value session.cookie_lifetime <jüngstes_gericht>
Dies wird ausgewertet noch bevor das PHP-Skript überhaupt gestartet wird. Früher geht's nicht, hat aber den kleinen Nachteil, dass es auf alle PHP-Cookies wirkt. Falls also neben dem Sitzungscookie noch andere, temporäre Cookies verwendet werden, ist diese Variante nicht so sinnvoll. Das dürfte aber eher selten bis gar nicht vorkommen.
Es hat schon seine Gründe, warum ich bei mir Cookies immer ausgeschaltet habe. Nur im Notfall mache ich eine Ausnahme und lasse temporäre Cookies zu, und nur für besonders "vertrauenswürdige" Seiten
Hatte ich auch eine Weile, aber inzwischen lasse ich stattdessen das Cookie-Verfallsdatum vom Browser automatisch auf das Browserende begrenzen. Einerseits wird dauerhaftes Nachschnüffeln so weiter verhindert, andererseits habe ich keinen Aufwand mit Seiten, die Cookies zwingend benötigen. Für mich ein akzeptabler Kompromiss.
Die setzen bei mir garantiert kein Cookie mehr. Ich werde sie direkt mal in die Liste der verbotenen Sites reinpacken. Google ist mittlerweile viel zu groß und marktbeherrschend geworden.
Nun, de.ask.com funktioniert auch sehr gut.
Noch ein Anti-Schnüffel-Tipp: In der hosts-Datei (bei Windows XP im Windows-Ordner unter system32/drivers/etc zu finden, unter Linux & Co. in /etc/) eine Zeile in der Art
127.0.0.1 localhost google-analytics.com ssl.google-analytics.com www.google-analytics.com
Google Analytics breitet sich wie die Pest aus.
Wenn die Sitzungsdauer abgelaufen ist, lösche ich manuell den Cookie und die Session, damit eine neue Session erzeugt werden kann.
Lösche einfach nur den Inhalt von $_SESSION mittels session_destroy(). Damit sind die Daten weg, aber der Cookie bleibt erhalten.
Aber dann bekommt der User nach einem erneuten Login doch dieselbe SID!? Ist das nicht unsicher
Nein, ist ja nix mehr drin. Ob du nun eine neue aufmachst, die leer ist, oder eine bestehende beibehältst, die leer ist, macht keinen Unterschied.