Bla: Sessions und Sicherheit

Beitrag lesen

Wo, im Browser? Nein, das geht in der Tat nicht. Aber wie oft meldest du dich gleichzeitig bei demselben Dienst mit mehr als einem Benutzernamen an?

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.

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.

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.

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.

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). Ü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.

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.