Einloggen in privaten Bereich - sicherheit??

[Arne]

Moin,

bin noch neu in PHP deshalb benötige ich euere Hilfe.
Ein User soll sich auf einer Seite einloggen können. Hat der User sich richtig eingeloggt (Name und Passwort richtig) wird ihm ein Cookie geschickt. Auf jeder unterseite auf die nur eingeloggte User dürfen wird geprüft ob das Cookie vorhanden ist. So weit so gut. Nun habe ich probiert ein Cookie zu faken also das Cookie manuell erstellt und konnte tatsächlich auf die unterseiten kommen auf die normal nur eingeloggte User dürfen. Das ist sehr unsicher. Wie kann ich das besser machen? Habe gelesen mit einer Session ID aber was muss da drin stehen? Wie löse ich mein Problem am besten und sichersten?

herzlichen danke - arne

[moritz]

Mit Sessions!
Bei erfolgreichem anmelden startest du die Sitzung mit session_start(); und vergibst eine eindeutige Sitzungs-ID mit session_id die du in eine Sitzungs-Variable speicherst:

  
session_start();  
$_SESSION['id']=session_id();  

Danach mit header("location:./") ne Weiterleitung machen!

Auf jeder nachfolgenden Seite beginnst(!) du wieder mit session_start(); und machst eine einfach Abfrage:

  
<?php  
session_start();  
if($_SESSION['id']!=session_id()){  
 die('Nicht angemeldet');  
}  

Ist halbwegs sicher und sollte so funktionieren

Grüße,
moritz

[Bademeister]

Hi moritz,

[...] und vergibst eine eindeutige Sitzungs-ID mit session_id

das ist i.a. unnoetig, das gechieht automatisch.

die du in eine Sitzungs-Variable speicherst:

session_start();
$_SESSION['id']=session_id();

  
Und Du vergibst auch gar keine, sondern speicherst nur die bestehende in eine Variable. Das ist in der Form auch unnoetig.  
  

> Danach mit header("location:./") ne Weiterleitung machen!  
  
Warum? Und wohin?  
  

> Auf jeder nachfolgenden Seite beginnst(!) du wieder mit session\_start(); und machst eine einfach Abfrage:  

~~~php
  

> <?php  
> session_start();  
> if($_SESSION['id']!=session_id()){  
>  die('Nicht angemeldet');  
> }  

Das fuehrt zu einem Warning, falls keine Session wiedehergestellt wurde, weil die Variable $_SESSION['id'] nicht existiert. Wenn sie doch existiert, ist sie zwingend gleich dem Rueckgabewert von session_id(). Wenn es der Kontext erfordert, dass Du abfragst, ob eine Session wiederhergestellt wurde, dann reicht es also, etwa in der Session eine Variable $_SESSION["exists"] zu setzen und diese beim Starten der Session auf Existenz zu pruefen.

Ausserdem ist das Nicht-Wiederherstellen einer Session kein Grund fuer das Skript, einfach Selbstmord zu begehen, gleich nachdem es invaliden HTML-Code zuruekgegeben hat, der lediglich aus einer haesslichen, nackten Fehlermeldung besteht. Oder?

Viele Gruesse,
der Bademeister

[moritz]

Hallo Bademeister,

»» Danach mit header("location:./") ne Weiterleitung machen!

Warum? Und wohin?

Ich habe manchmal Probleme Session Variablen auf der selben Seite zu verwenden auf welcher ich sie erstellt habe. die Weiterleitung würde hier einfach zur index-Datei erfolgen.

Dass ich die Sesssion id garnicht speichern brauch um z.b. in einem login-bereich die sitzung zu sichern, ist gut zu wissen, auch wenn ich nicht weiß welches warning du meinst.

Das die('Nicht angemeldet'); sollte hier nur zeigen dass dann die Sitzung halt ungültig ist...

Gruß und dank,
moritz

[Bademeister]

Hi,

Ich habe manchmal Probleme Session Variablen auf der selben Seite zu verwenden auf welcher ich sie erstellt habe.

Wie sehen die aus?

Dass ich die Sesssion id garnicht speichern brauch um z.b. in einem login-bereich die sitzung zu sichern, ist gut zu wissen, auch wenn ich nicht weiß welches warning du meinst.

Ich auch nicht :-) Es ist gar kein Warning, sondern nur eine Notice, etwa derart

Notice: Undefined index: id in [file_name],

die Du immer kriegst, wenn Du undefinierte Variablennamen oder, wie hier, undefinierte Indizes eines Arrays verwendest. Das ist ein Fehler und sollte vermieden werden.

Viele Gruesse,
der Bademeister

[moritz]

Hallo

»» Ich habe manchmal Probleme Session Variablen auf der selben Seite zu verwenden auf welcher ich sie erstellt habe.

Wie sehen die aus?

Ich kann einfach nicht auf sie zugreifen... Müssts aber nochmal ausprobieren - ist schon ein bisschen her und vielleicht wars ein anderes Problem.

Grüße,
moritz

P.S.: Mir fällt auch grad ein, dass beim einfachen abfragen von session-variablen ohne deren existenz zu prüfen, sich meine logs immer aufgebläht haben wenn sie nicht vorhanden waren.

[Tom]

Hello,

Auf jeder nachfolgenden Seite beginnst(!) du wieder mit session_start(); und machst eine einfach Abfrage:

<?php
session_start();
if($_SESSION['id']!=session_id()){
  die('Nicht angemeldet');
}

> Das fuehrt zu einem Warning, falls keine Session wiedehergestellt wurde, weil die Variable $\_SESSION['id'] nicht existiert. Wenn sie doch existiert, ist sie zwingend gleich dem Rueckgabewert von session\_id().  
  
Nö, nicht bevor mein Programm sie in die Session-Datei geschreiben hat. Sagst Du doch gerade selber.  
  
if (!isset($\_SESSION['id']))  
{  
    ## nicht angemeldet  
}  
  
  
Die Session selber hat ja nichts mit direkt damit zu tun, ob sich ein User bereits identifiziert hat. Erst, wenn er Identifikationsmerkmale gesendet hat, und z.B. auf 'anmelden' geklickt hat, beginnt das Authentifizierungsverfahren.  
  
Um diese Authentifizierung aufrecht zu erhalten, kann dann der Sessionmechanismus benutzt werden. Man könnte aber auch bei jedem Request die Identifikationsmerkmale erneut mitsenden, was aber die Summe der Requests unsicherer macht.  
  
  
  
  
  
  
Liebe Grüße aus dem schönen Oberharz  
  
  
Tom vom Berg  
![](http://selfhtml.bitworks.de/Virencheck.gif)  
  

-- 
Nur selber lernen macht schlau  
<http://bergpost.annerschbarrich.de>

[Bademeister]

»» Wenn sie doch existiert, ist sie zwingend gleich dem Rueckgabewert von session_id().

Nö,

Doch.

nicht bevor mein Programm sie in die Session-Datei geschreiben hat.

Ich weiss nicht, was Dein Programm damit zu tun hat, was in moritz' Programm in der Variable $_SESSION['id'] steht. Er hat da zu Beginn der Session

»» session_start();
»» $_SESSION['id']=session_id();

die Session-ID reingeschrieben.

;-)

Die Session selber hat ja nichts mit direkt damit zu tun, ob sich ein User bereits identifiziert hat.

Aber bevor ich auf eventuelle Sessionvariablen zugreife, muss ich pruefen, ob sie existieren, d.h. eine bestehende Session wiederhergestellt wurde, oder ob sie nicht existieren, weil eine neue Session gestartet wurde. Erst dann kann alles andere kommen.

Oder?

Viele Gruesse,
der Bademeister

[Tom]

Hello,

»» Wenn sie doch existiert, ist sie zwingend gleich dem Rueckgabewert von session_id().

Nö,

Doch.

Sorry, ich meinte doch, die ist nicht gleich $_SESSION['id']...
Da habe ich nicht richtig hingeguckt, was Du geschrieben hattest.

Du hast natürlich Recht, dass sie gleich session_id() ist.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

Moin,

[...]Wie kann ich das besser machen? Habe gelesen mit einer Session ID aber was muss da drin stehen? Wie löse ich mein Problem am besten und sichersten?

Du bist nahe dran. Die Session-ID ist das Herzstück einer Session, sie wird bei einem erfolgreichen Login generiert.

Wie diese SID zusammengesetzt ist, spielt keine Rolle, sie muss jedoch absolut eindeutig und schwer zu erraten sein und es ist zu gewährleisten, dass es beim Erzeugen der SID keine Duplikate gibt. Aus Gründen der Sicherheit sollte die SID keine Informationen zum Benutzer und auch keine Informationen zum Verfallsdatum einer Session enthalten (auch nicht synchron verschlüsselt), diese Dinge gehören auf dem Server gespeichert.

Hast Du solch eine SID, kommt die einmal auf den Server und zum Anderen in den Cookie zum Client.

Damit ist eine Session nur gültig, wenn

• der Client einen Cookie schickt mit einer SID, die es auch auf dem Server gibt
• das Verfallsdatum der SID nicht erreicht ist

Sicherheit erhöhen:

• https anstelle http
• secure-flag im Cookie setzen

Hotte

[Alexander (HH)]

Moin Moin!

Sicherheit erhöhen:

• https anstelle http
• secure-flag im Cookie setzen

Paranoia:

• prüfen, ob Remote-IP-Adresse von Request zu Request konstant bleibt (fällt bei Proxy-Hoppern wie z.B. AOL auf die Nase)
• prüfen, ob Browser-Header von Request zu Request konstant bleiben (User-Agent, Accept, Accept_Xxxx, ...)

Alexander

[Tom]

Hello,

Sicherheit erhöhen:

• https anstelle http
• secure-flag im Cookie setzen

Paranoia:

• prüfen, ob Remote-IP-Adresse von Request zu Request konstant bleibt (fällt bei Proxy-Hoppern wie z.B. AOL auf die Nase)
• prüfen, ob Browser-Header von Request zu Request konstant bleiben (User-Agent, Accept, Accept_Xxxx, ...)

Und was nützt das gegen Wolle S.?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

»» Paranoia:

Und was nützt das gegen Wolle S.?

Nicht viel.

Wer extremen Wert auf seine Daten legt, packt sie nicht unverschlüsselt auf einen problemlos aus dem Internet erreichbaren Server. Wenn man Udo Vetter glauben darf, ist eine handelsübliche Verschlüsselungssoftware auf einem abgeschirmten Server derzeit sicher genug, zusammen mit dem Recht zu schweigen. GegenRubber Hose Cryptanalysis hilft das wenig, aber zum Glück ist die in Deutschland (noch) illegal.

Ein paar Kubikmeter Beton sollen übrigens auch ganz hilfreich sein. Nicht, dass ich jetzt empfehlen würde, mit irgendwelchen Prominenten irgendwelche Szenen aus irgendwelchen Mafia-Filmen nachzuspielen. Einfach den Computer in Beton versenken und schon sind die Daten für eine ganze Weile ziemlich gut gesichert gegen Zugriffe aller Art.

Alexander

[Der Martin]

Hallo,

Ein paar Kubikmeter Beton sollen übrigens auch ganz hilfreich sein. Nicht, dass ich jetzt empfehlen würde, mit irgendwelchen Prominenten irgendwelche Szenen aus irgendwelchen Mafia-Filmen nachzuspielen.

... dennoch ein sehr interessanter Ansatz. Ich wüsste schon ein paar, die ich ins Casting für die Hauptrollen schicken würde. :-#

Einfach den Computer in Beton versenken und schon sind die Daten für eine ganze Weile ziemlich gut gesichert gegen Zugriffe aller Art.

So gesehen tut's auch ein Eimer konzentrierte Schwefelsäure, in dem die Festplatte gelagert wird. ;-)

So long,
 Martin

[Tom]

Hello,

Einfach den Computer in Beton versenken und schon sind die Daten für eine ganze Weile ziemlich gut gesichert gegen Zugriffe aller Art.

So gesehen tut's auch ein Eimer konzentrierte Schwefelsäure, in dem die Festplatte gelagert wird.

Wir sprachen von Datenschutz, nicht von -zerstörung :-)

Aber ausgehend von der Überlegung, dass die "Leute" bei einer Hausdurchsuchung ja irgendetwas finden wollen, sollte man ihrem Erfolgsdruck auch immer ein wenig mit "Anfüttermaterial" entgegenwirken, und die wichtigen Daten dann eben verschlüsselt auf dem versteckten Server lagern. Der kann ja auch beim Nachbarn stehen. Glasfaser-Netzwerkkabel kann man schließlich auch unter Putz verlegen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

Hello,

»» > Einfach den Computer in Beton versenken und schon sind die Daten für eine ganze Weile ziemlich gut gesichert gegen Zugriffe aller Art.
»»
»» So gesehen tut's auch ein Eimer konzentrierte Schwefelsäure, in dem die Festplatte gelagert wird.

Wir sprachen von Datenschutz, nicht von -zerstörung :-)

Richtig. Und schließlich bevorzugt die "Generation C64" Domestos (nach dem alten Rezept). Das frißt sich auch nicht so leicht durch den Lagerbehälter.

Aber ausgehend von der Überlegung, dass die "Leute" bei einer Hausdurchsuchung ja irgendetwas finden wollen, sollte man ihrem Erfolgsdruck auch immer ein wenig mit "Anfüttermaterial" entgegenwirken, und die wichtigen Daten dann eben verschlüsselt auf dem versteckten Server lagern. Der kann ja auch beim Nachbarn stehen. Glasfaser-Netzwerkkabel kann man schließlich auch unter Putz verlegen.

Du meinst das Prinzip des Novell-Servers an der University of North Carolina?

Und für die uniformierten Internet-Ausdrucker stellt man demonstrativ einen alten Pentium mit Win95 und einem ansehnlichen Playboy- oder Penthouse-Screensaver auf, quasi als Opfer-Elektrode?

Wobei: Glasfaser-Steckverbinder fallen auf. EADs, insbesondere die UP-Variante, wird kaum einer der Internet-Ausdrucker von TAE-Dosen unterscheiden können.

Alexander

[Auge]

Hallo

Und für die uniformierten Internet-Ausdrucker stellt man demonstrativ einen alten Pentium mit Win95 und einem ansehnlichen Playboy- oder Penthouse-Screensaver auf, quasi als Opfer-Elektrode?

OpferANODE!!!1!11!1!!elf!!1 ...

... obwohl ...

... gibt's da nicht den neudeutschen "Honeypot"? <amkopfkratz />*

Tschö, Auge

* Dafür, dass solcher Blödsinn möglich ist, liebe ich XML. :-)

[Alexander (HH)]

Moin Moin!

quasi als Opfer-Elektrode?

OpferANODE!!!1!11!1!!elf!!1 ...

Jede Anode ist eine Elektrode, aber nicht jede Elektrode ist eine Anode. Warum soll man eigentlich immer die positiven Anoden opfern? Gleiches Recht für alle Elektroden, für Opfer-Kathoden! Yeah!

Alexander

[Auge]

Hallo

»»  quasi als Opfer-Elektrode?
»»
»» OpferANODE!!!1!11!1!!elf!!1 ...

Jede Anode ist eine Elektrode, aber nicht jede Elektrode ist eine Anode. Warum soll man eigentlich immer die positiven Anoden opfern?

Weil wir das schon immer so gemacht haben[tm]!

Gleiches Recht für alle Elektroden, für Opfer-Kathoden! Yeah!

Jawollja! :-)

Tschö, Auge

[Tom]

Hello,

###---
Der Araber und der Kartoffel-Acker

Ein alter Araber lebt seit mehr als 40 Jahren in der Nähe von New York. Er würde gerne in seinem Garten Kartoffeln pflanzen, aber er ist allein und alt und schwach. Sein Sohn studiert in Paris. Er schreibt eine Email an seinen Sohn und erklärt ihm das Problem:

"Lieber Ahmed, ich bin sehr traurig, weil ich in meinem Garten keine Kartoffeln pflanzen kann. Ich bin sicher, wenn Du hier wärest, du könntest mir helfen, und könntest fur mich den Garten umgraben. Ich liebe dich. Dein Vater."

Am folgenden Tag erhält der alte Mann eine Email:

"Lieber Vater, bitte berühre nicht den Garten. Dort habe ich *die Sache* versteckt! Ich liebe Dich auch. Ahmed."

Um 4 Uhr morgens kommen die US Army, die Marines, das FBI, die CIA und die RANGERS zum Haus des alten Mannes. Sie suchen überall, nehmen den ganzen Garten auseinander, suchen jeden Millimeter ab, aber finden gar nichts. Enttäuscht gehen sie weg.

Am folgenden Tag erhält der alte Mann wieder eine Email vom Sohn:

"Lieber Vater, ich hoffe, dass der Garten mittlerweile umgegraben ist und Du die Kartoffeln jetzt pflanzen kannst. Mehr konnte ich für Dich nicht tun. Ich liebe Dich. Ahmed."

Alexander
###---

»»  quasi als Opfer-Elektrode?
»»
»» OpferANODE!!!1!11!1!!elf!!1 ...

Jede Anode ist eine Elektrode, aber nicht jede Elektrode ist eine Anode. Warum soll man eigentlich immer die positiven Anoden opfern?

Weil wir das schon immer so gemacht haben[tm]!

Gleiches Recht für alle Elektroden, für Opfer-Kathoden! Yeah!

Jawollja! :-)

###---

Also Ihr gefallt mir heute.
Ich bleib doch noch eine Weile und schmeiß mein Passwort zum Geheimserver nicht weg :-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Und für die uniformierten Internet-Ausdrucker stellt man demonstrativ einen alten Pentium mit Win95 und einem ansehnlichen Playboy- oder Penthouse-Screensaver auf, quasi als Opfer-Elektrode?

Opfer-Elektrode ist gut. Da passt dann auch der Thread https://forum.selfhtml.org/?t=187621&m=1247217 wieder ins Bild. Dabei hat der doch hier im Forum gar nichts zu suchen *g*

Wobei: Glasfaser-Steckverbinder fallen auf. EADs, insbesondere die UP-Variante, wird kaum einer der Internet-Ausdrucker von TAE-Dosen unterscheiden können.

Der Wechsel von Cat6 (mit typischer Nutzung 100MBit) auf Glasfaser darf ja auch erst irgendwo versteckt geschehen. Glasfaser ist nicht wegen der Geschwindigkeit wichtig, sondern wegen der "Nicht-Messbarkeit" der Leitung. Außerdem kann man damit auch mehr als 1000m überbrücken, sodass eingige Quadratmeter (Vor-)Gärten durchbuddelt werden müssten, um das Backup-System zu finden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

Der Wechsel von Cat6 (mit typischer Nutzung 100MBit) auf Glasfaser darf ja auch erst irgendwo versteckt geschehen. Glasfaser ist nicht wegen der Geschwindigkeit wichtig, sondern wegen der "Nicht-Messbarkeit" der Leitung. Außerdem kann man damit auch mehr als 1000m überbrücken, sodass eingige Quadratmeter (Vor-)Gärten durchbuddelt werden müssten, um das Backup-System zu finden.

Der Araber und der Kartoffel-Acker

Ein alter Araber lebt seit mehr als 40 Jahren in der Nähe von New York. Er würde gerne in seinem Garten Kartoffeln pflanzen, aber er ist allein und alt und schwach. Sein Sohn studiert in Paris. Er schreibt eine Email an seinen Sohn und erklärt ihm das Problem:

"Lieber Ahmed, ich bin sehr traurig, weil ich in meinem Garten keine Kartoffeln pflanzen kann. Ich bin sicher, wenn Du hier wärest, du könntest mir helfen, und könntest fur mich den Garten umgraben. Ich liebe dich. Dein Vater."

Am folgenden Tag erhält der alte Mann eine Email:

"Lieber Vater, bitte berühre nicht den Garten. Dort habe ich *die Sache* versteckt! Ich liebe Dich auch. Ahmed."

Um 4 Uhr morgens kommen die US Army, die Marines, das FBI, die CIA und die RANGERS zum Haus des alten Mannes. Sie suchen überall, nehmen den ganzen Garten auseinander, suchen jeden Millimeter ab, aber finden gar nichts. Enttäuscht gehen sie weg.

Am folgenden Tag erhält der alte Mann wieder eine Email vom Sohn:

"Lieber Vater, ich hoffe, dass der Garten mittlerweile umgegraben ist und Du die Kartoffeln jetzt pflanzen kannst. Mehr konnte ich für Dich nicht tun. Ich liebe Dich. Ahmed."

Alexander

[Arne]

Vielen Dank für euere zahlreichend Antworten, ich weiss jetzt was zu tun ist!
Eine frage hab ich aber noch: warum darf (ausser ich) wissen wann eine SID verfällt? Was könnte das für risiken haben?

[hotti]

Moooooiiin;

Eine frage hab ich aber noch: warum darf (ausser ich) wissen wann eine SID verfällt? Was könnte das für risiken haben?

Die Info "wann eine Session verfällt" gehört nur deswegen nicht in den SessionKey/SID damit sie nicht manipulierbar ist.

Viele Grüße,
Horst Haselhuhn

[Tom]

Hello,

Eine frage hab ich aber noch: warum darf (ausser ich) wissen wann eine SID verfällt? Was könnte das für risiken haben?

Ganz so ist das ja nun auch nicht.
Eine Session-ID hat üblicherweise eine begrenzte Länge. Auch wenn diese Länge 32 Stellen hexazezimal beträgt, möchte man dort keine Dinge einbauen, die nachvollziehbar sind, da diese den möglichen Schlüsselvorrat verringern würden. Also solllte die SID selbst nicht abhängig von der Zeit oder anderen Daten generiert werden. Sie ist einfach ein langer Schlüssel, der möglichst auch noch Unique sein sollte. In dieser Forderung steckt schon genügend Einschränkung.

Wenn der Server (Hier PHP) einen Cookie für die Session generiert, sendet er dem Client schon mit, wie lange dieser Cookie maximal gültig ist. Bei "Session-Cookies" (die nennen wir mal so) ist der Cookie solange gültig, bis die Fenster-Instanz am Browser geschlossen wird.

Auf dem Server läuft ein anderer Mechanismus. Im einfachsten Fall kümmert sich bei PHP der Garbage Collector (GC) um die Session. Die Session verfügt über eine Datei mit ihrer SID (meistens "SESS_$sid"). Diese Datei hat einen Zeitstempel, wann sie das letzte Mal angefasst wurde (A-Time), der nur vorhanden ist, wenn das Dateisystem das auch unterstützt (wird oft aus Faulheit oder Ersparnis nicht passend gemounted). Wenn diese Datei die _Mindestzeit_ von session.max_lifetime (siehe php.ini) nicht mehr angefasst wurde, dann darf sie vom GC gelöscht werden. Spätestens dann kann die Session nicht wieder aufgenommen (fortgesetzt) werden.

Eine Session besteht ja aus vielen einzelnen Requests, die sich untereinander nicht kennen. Sie erhalten einen Status (Zustand) nur durch die Sessiondaten und daa Programm (Script).

Da die Steuerung über den GC relativ schmuddelig ist, sollte die Sessiongültigkeit immer über das Anmelde- und rechteverfahren und z.B. die Datenbank gesteuert werden. Solange in der Datenbank ein gültiger Eintrag für die Session-ID vorhanden ist, sit die Session auch gültig. Die session.max_lifetime sollte so lang eingestellt werden, dass die in der Software einstellbare und in der Datenbank abgelegte Zeit auf jeden Fall kleiner ist, als die Lebensdauer der Session-Datei.

In einigen Installationen von PHP (z.B. auf Debian) wird das Aufräumen auch nicht mehr durch einen zufälligen PHP-Prozess vorgenommen, sondern durch einen Task, der sich als Cron-Job beim Cron-Daemon anmeldet, wenn das System hochfährt. Da wird die Lebensdauer der Datei dann wesentlich genauer eingehalten.

Es gibt auch Systeme, die für jeden User einen eigenen Session-Namen führen. Das hat den Vorteil, dass Manipulationen mit der Session-ID erkannt werden können.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

Hello,

Wenn der Server (Hier PHP) einen Cookie für die Session generiert, sendet er dem Client schon mit, wie lange dieser Cookie maximal gültig ist.

Bezogen auf den Cookie: Ja.

Die Gültigkeit einer Session hingegen, wird unabhängig davon festgelegt (genauer: Zeitlich begrenzt) und diese Info gehört auf den Server. Diese Unabhängigkeit ergibt sich allein schon aus der Tatsache, dass ein Cookie schon vor dem /serverseitig festgelegten/ zeitlichen Verfall der Session mit dem Schließen des Browserfensters verworfen wird.

Bei "Session-Cookies" (die nennen wir mal so) ist der Cookie solange gültig, bis die Fenster-Instanz am Browser geschlossen wird.

Ja Klar. Das bedeutet jedoch nicht, dass die Session evntl. länger gültig sein kann.

Viele Grüße aus dem verregneten KA,
Hotte