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.
Mittlerweile habe ich herausgefunden, ein Sitzungs-Cookie ist tatsächlich auch in der Browser-Terminologie ein Sitzungs-Cookie. Soll heißen: Werden alle Browserinstanzen geschlossen, wird auch der mittels PHP gesetzte Sitzungs-Cookie gelöscht.
Das ist der vorgesehene Fall, wenn dem Cookie kein Verfallsdatum mitgegeben wird, siehe Netscapes Cookie-Beschreibung, Stichwort expires. Alle Browser halten sich an diese Vorgaben.
Mit PHP-Sessions arbeite ich zum ersten Mal. Früher habe ich Sitzungen manuell programmiert mit Flatfiles oder auch mit einer DB, in die SID und der Zeitpunkt des letzten Zugriffs abgelegt wurden. 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.
Um Cookies habe ich in der Vergangenheit einen großen Bogen, weil ich sie selber nicht mag. Es war mir zwar bekannt, daß Cookies ohne Expires nach Schließen des Browsers gelöscht werden, aber wie genau PHP Sitzungs-Cookies handhabt, habe ich erst gestern rausgefunden.
Die Dinger heißen temporäre Cookies. Der Begriff Sitzungscookie bezeichnet vielmehr den Sitzungsmechanismus, sprich dass im Cookie nicht die eigentlichen Daten, sondern nur eine Kennung gespeichert wird, unter der die Daten auf dem Server abgelegt wurden (siehe übernächste Antwort unten). So ein Cookie könnte, je nach Anwendungsfall, auch ein Verfallsdatum und damit über das Schließen des Browsers hinaus Bestand haben.
»»
Was genau legt denn nun PHP im Sitzungs-Cookie ab? Die SID? Noch mehr? 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!? Oder noch schlimmer: Es existiert gar kein Cookie und ein Hacker legt einfach mal manuell eins an. Ich weiß nicht, ob das möglich ist!? Mit Cookies habe ich mich in der Vergangenheit allenfalls theoretisch beschäftigt, sie aber nie eingesetzt.
Ob oder wie man mit session_set_cookie_params() und session_start() einen dauerhaften Cookie ablegen kann, muß ich erst noch schauen.
Über die Einstellung session.cookie_lifetime.
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."
Wie nun ein dauerhaftes Session-Cookie setzen? Mit session_set_cookie_params() oder setcookie()?
Den Server andererseits interessiert der Cookiename nicht, er benutzt ihn nur, um vom Browser den Cookieinhalt zu bekommen. Die einzelnen Sitzungen unterscheidet der Server anhand der Cookieinhalts.
Was genau speichert PHP denn in dem Session-Cookie?
Eine lange Kette zufälliger Zeichen. Das ist quasi die Aktennummer, unter der PHP auf dem Server die zur Sitzung gehörigen Daten abgelegt hat. Der Witz an Sitzungen ist, dass die Daten auf dem Server bleiben und somit a) nicht bei jeder Anfrage vom Browser übermittelt werden müssen (was Zeit kostet), und sie vor allen Dingen b) vor unkontrollierten Manipulationen durch Benutzer geschützt sind.
Würde ich statt der Sitzungskennung die Daten selbst in den Cookie schreiben (etwa "i=23;text='bla'"), bräuchtest du als Benutzer nur einen Texteditor und könntest diese Daten ändern.Sitzungen haben allerdings auch einen Nachteil, nämlich wenn sie für dauerhafte Einstellungen genutzt werden. Die Sitzungskennung mutiert dann zu einer eindeutigen Benutzerkennung, einer Personenkennziffer. Da die Sitzungskennung bei jeder Anfrage an den Server übermittelt wird, könnte der Anbieter lebenslang alle Aktionen des Benutzers genau nachverfolgen - mit Datenschutz hat das nicht mehr viel zu tun.
Google macht das zum Beispiel; jeder Google-Benutzer erhält eine Sitzungskennung in einem Cookie, dessen Ablaufdatum im Jahre 2038 liegt (was für sich alleine genommen schon Schwachsinn ist, denn ein Besucher, der 30 Jahre nicht wieder kommt, hat offensichtlich wenig Interesse an den Diensten).
Das war mir nicht bekannt. Deine Argumentation ist vollkommen richtig. Wenn es nur um Personalisierung im Interesse des Besuchers ginge, wäre eine so lange Laufzeit vollkommen unbegründet. Man muß wohl davon ausgehen, daß die kräftig loggen. 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 (das sind maximal drei bis vier bei mir, z. B. Ebay - nein, denen traue ich nicht wirklich, aber es ist einfach bequemer, Cookies zuzulassen, solange ich bei Auktionen mitbiete) lasse ich dauerhafte Cookies zu, und das auch nur, solange ich sie in dem Moment brauche. Greife ich nicht mehr regelmäßig auf die Seiten zu, fliegen die dauerhaften Cookies auch raus.
Über diese Kennung werden angeblich nur die Einstellungen für die Suche gespeichert, es ist aber ohne weiteres möglich, damit sämtliche Suchanfragen zu verbinden und somit ein Suchprofil zu erstellen. Und da Google mittlerweile auf sehr vielen Drittseiten vertreten ist, sei es durch Google Adsense, sei es durch Google Analytics, bestünde auch die Möglichkeit abseits der Google-Suche das Benutzerverhalten sehr genau nachzuvollziehen: Der gläserne Verbraucher, (fast) egal, welche Webseite du aufrufst, Google weiß es.
siehe oben. 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. Es wird Zeit für eine nicht-kommerzielle Open-Source-Suchmaschine.
Wenn die Sitzungsdauer abgelaufen ist, lösche ich manuell den Cookie und die Session, damit eine neue Session erzeugt werden kann. Es ginge zwar auch ohne Löschen der Sitzung, aber so halte ich es für sicherer, weil der User ansonsten nach einem erneuten Login die alte Sitzung übernehmen würde.
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, selbst wenn die Session-Variablen neu angelegt werden?