Tobias2: Sessions und Sicherheit

Hallo liebe Helfer,

ich habe mal ein paar Anfängerfragen, die mir zum Thema Sicherheit durch den Kopf gehen. Vielleicht bin ich auch auf dem Holzweg, aber hier erst mal, um was es geht.

1. Ist es möglich, von einem fremden Server aus PHP-Skripte (z. B. Konfigurationsdateien, in denen die Zugangsdaten für die Datenbank stehen) mit fopen auszulesen und den Quellcode anzuzeigen? Wenn das möglich ist, wie läßt sich das verhindern?
2. Wie verhält es sich, wenn von einem Rechner zwei Logins mit unterschiedlichen Benutzerangaben stattfinden (unterschiedliche Personen)? Muß vor session_start() mit session_name() eine Name gesetzt werden, damit unterschiedliche Cookies gesetzt werden? Wenn diese Vorgehensweise richtig ist, kann dann ein zweiter Benutzer desselben Rechners trotzdem irgendwie in die Session des ersten Benutzer reinkommen? Wie kann das Skript nach dem Einloggen unterscheiden, auf welchen Cookie es zugreifen soll? Muß es in einer Session-Variable eine Kennung für den Nutzer mitspeichern, um danach den richtigen Nutzer zu erkennen? Wenn im Cookie dauerhaftes Eingeloggt-bleiben vermerkt wurde, wie sieht es dann aus? Ein praktisch denkbarer Fall: In einer WG benutzen verschiedene Personen denselben E-Mail-Provider oder Ebay und lassen den Einlogstatus vom Browser speichern (keine Ahnung, ob E-Mail-Provider wirklich Cookies setzen, nur mal hypothetisch angenommen. Ebay setzt jedenfalls Cookies zum Status, den Inhalt weiß ich nicht).
3. Keine Frage zur Sicherheit, sondern zum Umgang mit Session-Cookies: Angenommen, Cookies sind abgeschaltet. Der User schickt das Einlogg-Formular ab. Das Skript prüft, ob ein Cookie gesetzt wurde. Wenn ja, findet die Überprüfung der Zugangsdaten statt. Wenn nein, wird der User auf die fehlende Cookie-Unterstützung hingewiesen und das Formular erneut ausgegeben. Der User schaltet Cookies ein und sendet das Formular ab. Nun wurde aber kein Cookie gesetzt (wenn der User das Formular nicht selbst nach Cookie-Einschaltung aktualisiert hat). Die Folge ist: Das Skript bemängelt wieder nicht eingeschaltete Cookies. Kann man das umgehen?

Liebe Grüße
Tobi

    1. Ist es möglich, von einem fremden Server aus PHP-Skripte (z. B. Konfigurationsdateien, in denen die Zugangsdaten für die Datenbank stehen) mit fopen auszulesen und den Quellcode anzuzeigen? Wenn das möglich ist, wie läßt sich das verhindern?

    Das ist theorethisch möglich, aber die Installationsroutinen achten darauf, dass genau das nicht passiert. D.h. man müsst den Webserver schon entsprechend konfigurieren, was man aber nicht tun sollte.

    1. Wie verhält es sich, wenn von einem Rechner zwei Logins mit unterschiedlichen Benutzerangaben stattfinden (unterschiedliche Personen)? Muß vor session_start() mit session_name() eine Name gesetzt werden, damit unterschiedliche Cookies gesetzt werden?

    Da werden serverseitig zwei Sessions gefahren. Bei den Cookies weiss ich nicht so genau, ob da ein Cookieaustausch möglich ist, Cookies sind rechner-, nutzer- und browsergebunden, wenn ich mich nicht täusche.

    Wenn diese Vorgehensweise richtig ist, kann dann ein zweiter Benutzer desselben Rechners trotzdem irgendwie in die Session des ersten Benutzer reinkommen?

    Die Sessiondaten sollten nicht lokal gespeichert werden, wenn Sessioncookies gespeichert werden, könnte das passieren, allerdings gibt es wohl auch verschlüsselte, sichere Cookies.

    Wie kann das Skript nach dem Einloggen unterscheiden, auf welchen Cookie es zugreifen soll?

    Es findet nur eine oder keine rechner-, nutzer- und browsergebunden Cookie.

    Muß es in einer Session-Variable eine Kennung für den Nutzer mitspeichern, um danach den richtigen Nutzer zu erkennen?

    Nein, Sessions sind von Berechtigungssystemen, wie es übrigens auch dieses Forum kennt zu trennen, Cookies sind kleine Helfer.

    1. Keine Frage zur Sicherheit, sondern zum Umgang mit Session-Cookies: Angenommen, Cookies sind abgeschaltet. Der User schickt das Einlogg-Formular ab. Das Skript prüft, ob ein Cookie gesetzt wurde. Wenn ja, findet die Überprüfung der Zugangsdaten statt. Wenn nein, wird der User auf die fehlende Cookie-Unterstützung hingewiesen und das Formular erneut ausgegeben. Der User schaltet Cookies ein und sendet das Formular ab. Nun wurde aber kein Cookie gesetzt (wenn der User das Formular nicht selbst nach Cookie-Einschaltung aktualisiert hat). Die Folge ist: Das Skript bemängelt wieder nicht eingeschaltete Cookies. Kann man das umgehen?

    Indem Du Sitzungen ohne Cookies fährst bspw. Das oben geschilderte Szenario habe ich aber nicht ganz verstanden, ist ohnehin nicht mein Spezialgebiet.

    1. Indem Du Sitzungen ohne Cookies fährst bspw. Das oben geschilderte Szenario habe ich aber nicht ganz verstanden, ist ohnehin nicht mein Spezialgebiet.

      Z. B. so (Pseudo-Code):

      session_start();

      $login = FALSE;

      if (isset($_SESSION['login']))
        {
         if  (Zeit nicht abgelaufen) $login = true;
         else fehler: Zeit abgelaufen
        }

      else if (isset($_POST['aufruf kommt von loginformular']) && count($_COOKIE) == 0)
        {
          fehler: Cookies ausgeschaltet
        }

      else if (isset($_POST['aufruf kommt von loginformular']))
        {
          Login-Daten prüfen
          in Ordnung? => $login = true; $_SESSION['login'] = true; $_SESSION['zugriffszeit'] = time();
        }

      if (!$login)

      {
         evtl. Fehler-Ausgabe:
          a. Zeit abgelaufen
          b. Cookies ausgeschaltet

      Formular anzeigen
         exit;

      Wird bei Fall b. das Formular abgesendet, konnte   session_start(); keinen Cookie setzen. Erst nach dem Abschicken wird das Cookie gesetzt. Da es aber zuvor keins gab, ist die Abfrage if (isset($_POST['gesendet']) && count($_COOKIE) == 0) wieder wahr, und der User landet wieder an dieser Stelle, obwohl ja schon die Cookies eingeschaltet sind. Erst beim zweiten Absenden ist die Abfrage nicht mehr wahr, und die Loginüberprüfung findet statt.
       }

  1. Moin,

    1. Ist es möglich, von einem fremden Server aus PHP-Skripte (z. B. Konfigurationsdateien, in denen die Zugangsdaten für die Datenbank stehen) mit fopen auszulesen und den Quellcode anzuzeigen? Wenn das möglich ist, wie läßt sich das verhindern?

    Mit fopen ist auf fremden Servern alles ausgelesen werden, was auch per Browser zugänglich ist. Schützen kann man sich davor z.B. indem man die Rechte von config-Dateien so setzt, dass sie nicht vom Apache ausgeliefert werden, oder sie außerhalb des Document-Root des Webservers platziert.

    S. hierzu http://localhost/books/php_manual/function.fopen.html

    Zu deiner zweiten Frage: Afaik kümmert sich PHP/der Webserver darum.
    http://localhost/books/php_manual/ref.session.html

    Wenn PHP keinen Cookie setzen kann, verwendet es afaik automatisch URL-Parameter statt der Cookies.

    Gruß

    Stareagle

    1. Mit fopen ist auf fremden Servern alles ausgelesen werden, was auch per Browser zugänglich ist. Schützen kann man sich davor z.B. indem man die Rechte von config-Dateien so setzt, dass sie nicht vom Apache ausgeliefert werden, oder sie außerhalb des Document-Root des Webservers platziert.

      Kannst Du das mal kurz erklären, wie man das genau macht?

      S. hierzu http://localhost/books/php_manual/function.fopen.html

      Zu deiner zweiten Frage: Afaik kümmert sich PHP/der Webserver darum.
      http://localhost/books/php_manual/ref.session.html

      Wenn PHP keinen Cookie setzen kann, verwendet es afaik automatisch URL-Parameter statt der Cookies.

      Das hängt davon ab, wie PHP konfiguriert ist. Aber aus Sicherheitsbedenken will ich sowieso Sitzungen nicht über Get-Parameter identifizieren.

      Gruß

      Stareagle

      1. Moin,

        Kannst Du das mal kurz erklären, wie man das genau macht?

        Dazu müsste man wissen auf was für einem System/Webspace die entsprechende Seite liegt. Wobei: Das mit den Rechten in Quatsch, wie ich gerade festgestellt habe... PHP wird unter dem gleichen User wie der Webserver ausgeführt...

        Was die andere Möglichkeit angeht: Angenommen (Unix vorausgesetzt) deine Seite liegt unter

          
        /var/www/seite/htdocs  
        
        

        Du legst jetzt ein Verzeichnis

          
        /var/www/seite/config  
        
        

        an. Da kommen deine Konfigs rein. Über den Dateisystempfad kommt PHP immer noch ran, aber über die URL kommt man nicht mehr ran, da der Apache nur die Sachen in htdocs ausliefern kann. PHP bietet aber noch einen SecureMode (oder so ähnlich) bei dem PHP in einem Verzeichnis "einsperren" kannst. Das musst du ebenfalls entsprechend konfigurieren. Hier verweise ich auf das PHP Manual. ([link=http://www.php.net])

        Das hängt davon ab, wie PHP konfiguriert ist. Aber aus Sicherheitsbedenken will ich sowieso Sitzungen nicht über Get-Parameter identifizieren.

        Hmm, das könnte datenschutzrechtliche Probleme aufwerfen. Cookies werden da von einige Juristen bereits als Erhebung personenbezogener Daten beurteilt... Je nach dem was für eine Seite es ist solltest du dich da mal schlau machen. Stichworte: Telemediengesetz bzw. Kommentare dazu. Da das TMG recht neu ist, sind auch die Kommentare zum Telediestegesetz bzw. Teledienstedatenschutzgesetz interessant. Der Datenschutzteil des TMG ist fast identisch mit dem TDDSG... Natürlich ist auch Bundesdatenschutzgesetz zu beachten...

        Gruß

        Stareagle

        1. Was die andere Möglichkeit angeht: Angenommen (Unix vorausgesetzt) deine Seite liegt unter

          /var/www/seite/htdocs

          Du legst jetzt ein Verzeichnis

          /var/www/seite/config

          an. Da kommen deine Konfigs rein. Über den Dateisystempfad kommt PHP immer noch ran, aber über die URL kommt man nicht mehr ran, da der Apache nur die Sachen in htdocs ausliefern kann. PHP bietet aber noch einen SecureMode (oder so ähnlich) bei dem PHP in einem Verzeichnis "einsperren" kannst. Das musst du ebenfalls entsprechend konfigurieren. Hier verweise ich auf das PHP Manual. ([link=http://www.php.net])

          Ok, dachte ich mir schon so. Das ist dann die maximale Sicherheit - selbst wenn mal der PHP-Interpreter ausfällt, kommt niemand von außen mehr ran.

          Kann PHP auch mit relativer Pfadangabe darauf schreibend zugreifen, um die Config zu setzen?

          chdir("../config/"); // von htdocs aus
          $handle = fopen("config.php", "w");

          Ansonsten müßte die config.php per FTP übertragen werden.

          Das hängt davon ab, wie PHP konfiguriert ist. Aber aus Sicherheitsbedenken will ich sowieso Sitzungen nicht über Get-Parameter identifizieren.

          Hmm, das könnte datenschutzrechtliche Probleme aufwerfen. Cookies werden da von einige Juristen bereits als Erhebung personenbezogener Daten beurteilt... Je nach dem was für eine Seite es ist solltest du dich da mal schlau machen. Stichworte: Telemediengesetz bzw. Kommentare dazu. Da das TMG recht neu ist, sind auch die Kommentare zum Telediestegesetz bzw. Teledienstedatenschutzgesetz interessant. Der Datenschutzteil des TMG ist fast identisch mit dem TDDSG... Natürlich ist auch Bundesdatenschutzgesetz zu beachten...

          Eigentlich nicht. In dem Cookie werden die Sitzungsvariablen nicht gespeichert. Die werden in einer Sessiondatei in einem temporären Verzeichnis gespeichert (session.save_path in der php.ini gibt an, wo das ist) und verlassen nie den Server.

    1. Wie verhält es sich, wenn von einem Rechner zwei Logins mit unterschiedlichen Benutzerangaben stattfinden (unterschiedliche Personen)? Muß vor session_start() mit session_name() eine Name gesetzt werden, damit unterschiedliche Cookies gesetzt werden? Wenn diese Vorgehensweise richtig ist, kann dann ein zweiter Benutzer desselben Rechners trotzdem irgendwie in die Session des ersten Benutzer reinkommen? Wie kann das Skript nach dem Einloggen unterscheiden, auf welchen Cookie es zugreifen soll? Muß es in einer Session-Variable eine Kennung für den Nutzer mitspeichern, um danach den richtigen Nutzer zu erkennen? Wenn im Cookie dauerhaftes Eingeloggt-bleiben vermerkt wurde, wie sieht es dann aus? Ein praktisch denkbarer Fall: In einer WG benutzen verschiedene Personen denselben E-Mail-Provider oder Ebay und lassen den Einlogstatus vom Browser speichern (keine Ahnung, ob E-Mail-Provider wirklich Cookies setzen, nur mal hypothetisch angenommen. Ebay setzt jedenfalls Cookies zum Status, den Inhalt weiß ich nicht).

    Also das Session-System von PHP basiert überhaupt nicht auf Cookies. Man kann zwar dieses System mit Cookies ersetzen, dies bringt jedoch einige Nachteile gegenüber der ersteren Variante. Die Sache mit den Sessions basiert darauf, dass an die URI noch etwas angehängt wird, nämlich die sehr lange SessionID. Aufgrund dieser ID kann das Script dann auf bestimmte Variablen zugreifen, sprich den User erkennen. Jedesmal, wenn die komplett identische URI (also mit derselben SessionID) aufgerufen wird, wird der User erkannt, egal ob die Anfrage von derselben IP ausgeht oder nicht (ausser man baut im Script eine entsprechende Kontrolle ein).
    Zu dem Cookie-und-verschiedene-PC-Benutzer-Problem: Bei Windows XP gibt es ja verschiedene Benutzerkonten. Modernere Browser speichern daher Cookies benutzerabhängig. Wenn das nicht geht: Dauerhaftes eingeloggt-bleiben eben nicht möglich.

    Zu 3.:
    Da ich sowieso ein System mit Sessions (siehe oben) empfehlen würde, stellt sich dieses Problem nicht.

    mfg
    Rato

    1. Also das Session-System von PHP basiert überhaupt nicht auf Cookies. Man kann zwar dieses System mit Cookies ersetzen, dies bringt jedoch einige Nachteile gegenüber der ersteren Variante.

      Vor allem aber entscheidende Sicherheitsvorteile. SID per URL hat viele Sicherheitslücken.

      1. Hello,

        Vor allem aber entscheidende Sicherheitsvorteile. SID per URL hat viele Sicherheitslücken.

        Welche sind das?

        Harzliche Grüße vom Berg
        http://www.annerschbarrich.de

        Tom

        --
        Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
        Nur selber lernen macht schlau

        1. Hello,

          Vor allem aber entscheidende Sicherheitsvorteile. SID per URL hat viele Sicherheitslücken.

          Welche sind das?

          Harzliche Grüße vom Berg
          http://www.annerschbarrich.de

          Tom

          Aus dem PHP-Manual:

          Sessions und Sicherheit
          Externe Links: Session fixation

          Das Session-Modul bietet keine Garantie dafür, dass Informationen, die Sie in einer Session speichern, nur vom Benutzer gesehen werden können, der die Session erzeugt hat. Sie müssen zusätzliche Maßnahmen ergreifen, um die Integrität der Session ihrer Wichtigkeit entsprechend angemessen aktiv zu schützen.

          Schätzen Sie die Wichtigkeit der Daten ab, die in Ihren Sessions transportiert werden und treffen Sie zusätzliche Schutzmaßnahmen -- in der Regel bezahlen Sie dafür mit einer geringeren Benutzerfreundlichkeit. Wenn Sie z.B. Benutzer vor einfachen Social Engineering Tactics (Anm. des Übersetzers: Techniken der Ausnutzung menschlicher Schwächen) schützen wollen, müssen Sie session.use_only_cookies aktivieren. Cookies müssen dann benutzerseitig auf jeden Fall aktiviert sein, weil Sessions sonst nicht funktionieren.

          Es gibt mehrere Wege, über die eine Sessio-ID an Dritte gelangen kann. Eine entführte Session-ID ermöglicht diesen, auf alle Daten zuzugreifen, die mit dieser Session-ID verbunden sind. Erstens sind das URLs, die Session-IDs enthalten. Wenn Sie auf eine externe Site verweisen, könnte die URL inklusive Session-ID in den Referrer-Logs der externen Site gespeichert werden. Zweitens kann ein aktiverer Angreifer Ihren Netzwerkverkehr abhören. Falls Ihr Netzwerkverkehr nicht verschlüsselt ist, werden Session-IDs im Klartext über das Netzwerk übertragen. Hier ist die Lösung, auf Ihrem Server SSL zu implementieren und die Verwendung für Ihre Benutzer obligatorisch zu machen.

          =>

          Ohne Cookies kann die SID und damit die Sitzung ständig in falsche Hände gelangen.

          1. Ohne Cookies kann die SID und damit die Sitzung ständig in falsche Hände gelangen.

            Kann das mit Cookies nicht auch passieren?

            mfg
            Rato

            1. Ohne Cookies kann die SID und damit die Sitzung ständig in falsche Hände gelangen.

              Kann das mit Cookies nicht auch passieren?

              mfg
              Rato

              Das weiß ich nicht. Vermutlich schon. Aber die Wahrscheinlichkeit, daß es passiert, scheint mir bei per URL-überreichten SIDs größer zu sein. Ich mag zwar keine Cookies und würde die andere Variante auch lieber einsetzen (so habe ich es früher gemacht), weil es einfacher ist und auch für den User bequemer, aber die Argumente im PHP-Manual und eine Suche zum Thema im Web haben mich erst einmal davon überzeugt, mit Cookies zu arbeiten.

            2. Yerf!

              Ohne Cookies kann die SID und damit die Sitzung ständig in falsche Hände gelangen.

              Kann das mit Cookies nicht auch passieren?

              Nur per Überwachung des Netzwerktraffics, nicht aber über den Refferer oder Copy&Paste der URL.

              Gruß,

              Harlequin

        2. Vor allem aber entscheidende Sicherheitsvorteile. SID per URL hat viele Sicherheitslücken.

          Welche sind das?

          Benutzer A ist bei einem Dienst eingeloggt, sieht dort eine tolle Seite, kopiert die URL aus der Adressleiste und schickt sie an alle Kollegen der Abteilung, "schaut mal, voll lustig". Da in der URL auch die Sitzungskennung steckt, können sich jetzt alle Kollegen unter As Benutzerkonto ausbreiten. Dumm gelaufen, mit einem Cookie wär' das nicht passiert.

          Kurz: Die Kennung hat in der URL nichts zu suchen. Es gibt serverseitig keinen Grund, sie dort reinzupacken, denn es gibt benutzerseitig keinen Grund, Cookies nicht zumindest als temporäre zu akzeptieren.

    2. Moin!

      Also das Session-System von PHP basiert überhaupt nicht auf Cookies.

      Diese Aussage ist falsch.

      Man kann zwar dieses System mit Cookies ersetzen, dies bringt jedoch einige Nachteile gegenüber der ersteren Variante. Die Sache mit den Sessions basiert darauf, dass an die URI noch etwas angehängt wird, nämlich die sehr lange SessionID.

      Und diese ist halbwahr.

      PHP nutzt primär Cookies, um die Session-ID zu transportieren. Als hilfsweise Alternative bietet es an, die Session-ID auch in der URL zu transportieren. Was genau geschieht, kann man konfigurieren. Standard ist, Cookies zu verwenden und die URL-Methode als Hilfsmethode immer mitzuverwenden.

      Das sieht dann so aus, dass die erste Seite, auf der eine Session gestartet wird, ein Cookie setzt und alle Links und Formulare mit der Session-ID anreichert. Die nächste aufgerufene Seite erkennt, ob ein Session-Cookie zurückgeschickt wurde - in diesem Fall wird auf das Anhängen der Session-ID in der URL verzichtet. Wird kein Cookie festgestellt, verhält sich PHP wie bei der ersten Seite: Das Cookie wird wieder gesetzt, und alle Links enthalten die Session-ID.

      Ein User, der sich bei jedem gesetzten Cookie informieren läßt und fallweise entscheidet, wird also auf jeder neu aufgerufenen Seite so lange mit der Cookiemeldung genervt, bis er das Cookie entweder akzeptiert (ab dann surft er ohne Session-IDs in der URL) oder dauerhaft ablehnt (dann sieht er nur die Meldung nicht mehr, PHP versucht aber weiterhin, das Cookie zu setzen).

      - Sven Rautenberg

      --
      "Love your nation - respect the others."
      1. Moin!

        Also das Session-System von PHP basiert überhaupt nicht auf Cookies.

        Diese Aussage ist falsch.

        Man kann zwar dieses System mit Cookies ersetzen, dies bringt jedoch einige Nachteile gegenüber der ersteren Variante. Die Sache mit den Sessions basiert darauf, dass an die URI noch etwas angehängt wird, nämlich die sehr lange SessionID.

        Und diese ist halbwahr.

        PHP nutzt primär Cookies, um die Session-ID zu transportieren. Als hilfsweise Alternative bietet es an, die Session-ID auch in der URL zu transportieren. Was genau geschieht, kann man konfigurieren. Standard ist, Cookies zu verwenden und die URL-Methode als Hilfsmethode immer mitzuverwenden.

        Hm, in der php.ini steht bei mir zwar session.use_only_cookies Off, aber das hat trotzdem nicht gefunzt. Es wurde keine URL-SID generiert.

        Btw: Kann man per Skript PHP dazu veranlassen, nur Cookies zu senden, oder geht das nur über die php.ini? Die beiden anderen Fälle wären auch interessant (per Skript beides erzwingen bzw. nur URL-codiert und keine Cookies schicken).

        • Sven Rautenberg
    1. Ist es möglich, von einem fremden Server aus PHP-Skripte (z. B. Konfigurationsdateien, in denen die Zugangsdaten für die Datenbank stehen) mit fopen auszulesen und den Quellcode anzuzeigen?

    Nein, die üblicherweise richtige Konfiguration vorausgesetzt. Der Webserver gibt den Quellcode von Skripten generell nicht aus, sondern nur dass, was die Skripte ihrerseits ausspucken. Über anderweitige Zugänge (für fopen namentlich FTP) ist der Zugriff auf die Quellcodes nur mit Passwort möglich.

    1. Wie verhält es sich, wenn von einem Rechner zwei Logins mit unterschiedlichen Benutzerangaben stattfinden (unterschiedliche Personen)? Muß vor session_start() mit session_name() eine Name gesetzt werden, damit unterschiedliche Cookies gesetzt werden?

    Eine Sitzung wird nicht über den Cookienamen identifiziert, sondern über den Inhalt des Cookies, und dieser besteht automatisch aus einer zufälligen, jeweils nur eine einzelne Sitzung identifizierenden Zeichenfolge.

    Cookies kannst du dir im Grunde einfach als Dateien vorstellen, jede Datei hat einen Namen, mit dem sie angesprochen wird, und einen Inhalt. Auf verschiedenen Rechnern kann es Dateien mit dem gleichen Namen, aber unterschiedlichem Inhalt geben.

    Wenn diese Vorgehensweise richtig ist, kann dann ein zweiter Benutzer desselben Rechners trotzdem irgendwie in die Session des ersten Benutzer reinkommen?

    Jeder kann anderer Leute Sitzungen kapern, allerdings braucht er dazu die Kennung, also besagte Zeichenfolge.

    Wenn im Cookie dauerhaftes Eingeloggt-bleiben vermerkt wurde, wie sieht es dann aus?

    Die auf dem Server gespeicherten Sitzungsdaten verfallen entweder nicht oder nur nach langer Zeit (könnte zu unangehm viel Datenmüll führen), oder im Cookie ist der Benutzername zusammen mit einem geheimen Geheimcode gespeichert, dessen Geheimnis nur der Server entschlüsseln kann (ansonsten könnte sich jeder innerhalb einer Minute ein Cookie selbst basteln und anderer Leute Daten auslesen).

    In einer WG benutzen verschiedene Personen denselben E-Mail-Provider oder Ebay und lassen den Einlogstatus vom Browser speichern

    Deswegen nutzt der kluge Nutzer diese Funktion niemals auf Rechnern, auf die andere Zugriff haben. Und kluge Programmierer sorgen dafür, dass vor wichtige Funktionen im Webangebot in jedem Fall, egal ob dauereingeloggt oder nicht, eine weitere Passwortabfrage kommt (was natürlich nichts nützt, wenn das Passwort im Browser gespeichert ist).

    1. Keine Frage zur Sicherheit, sondern zum Umgang mit Session-Cookies: Angenommen, Cookies sind abgeschaltet. Der User schickt das Einlogg-Formular ab. Das Skript prüft, ob ein Cookie gesetzt wurde. Wenn ja, findet die Überprüfung der Zugangsdaten statt. Wenn nein, wird der User auf die fehlende Cookie-Unterstützung hingewiesen und das Formular erneut ausgegeben. Der User schaltet Cookies ein und sendet das Formular ab. Nun wurde aber kein Cookie gesetzt (wenn der User das Formular nicht selbst nach Cookie-Einschaltung aktualisiert hat). Die Folge ist: Das Skript bemängelt wieder nicht eingeschaltete Cookies. Kann man das umgehen?

    Ja, durch einen Zwischenschritt. Nach Absenden des Formulars wird der Inhalt geprüft, dann (bei korrekten Zugangsdaten) die Sitzung aufgemacht (nicht schon vor Schritt 1) und eine Zwischenseite ausgegeben, die a) den Keks setzt und b) automatisch zu einer Keksprüfseite weiterleitet, die ihrerseits die Keksexistenz prüft und je nach Ergebnis zur Kein-Keks-Korrekturklage oder zur gewünschten Inhaltsseite weiterleitet. Die Datenübergabe zwischen den einzelnen Schritten erfolgt durch Übermittlung der Sitzungskennung als URL-Parameter.
    Diese Vorgehensweise hat unter Umständen gleichzeitig den Vorteil, dass man Leute, die kein Cookie brauchen, gar nicht erst mit Cookies belästigt.

    1. Nein, die üblicherweise richtige Konfiguration vorausgesetzt. Der Webserver gibt den Quellcode von Skripten generell nicht aus, sondern nur dass, was die Skripte ihrerseits ausspucken. Über anderweitige Zugänge (für fopen namentlich FTP) ist der Zugriff auf die Quellcodes nur mit Passwort möglich.

      »»

      Ist die Konfiguration über allow_url_fopen einzustellen?

      Eine Sitzung wird nicht über den Cookienamen identifiziert, sondern über den Inhalt des Cookies, und dieser besteht automatisch aus einer zufälligen, jeweils nur eine einzelne Sitzung identifizierenden Zeichenfolge.

      Cookies kannst du dir im Grunde einfach als Dateien vorstellen, jede Datei hat einen Namen, mit dem sie angesprochen wird, und einen Inhalt. Auf verschiedenen Rechnern kann es Dateien mit dem gleichen Namen, aber unterschiedlichem Inhalt geben.

      Ja, das weiß ich. Das Problem ist ja nur, standardmäßig wird das Session-Cookie als PHPSESSID abgelegt, wenn das so in session.name in der php.ini konfiguriert wurde. Demnach könnte ja kein Cookie für einen zweiten Benutzer abgelegt werden.

      Wenn im Cookie dauerhaftes Eingeloggt-bleiben vermerkt wurde, wie sieht es dann aus?

      Die auf dem Server gespeicherten Sitzungsdaten verfallen entweder nicht oder nur nach langer Zeit (könnte zu unangehm viel Datenmüll führen), oder im Cookie ist der Benutzername zusammen mit einem geheimen Geheimcode gespeichert, dessen Geheimnis nur der Server entschlüsseln kann (ansonsten könnte sich jeder innerhalb einer Minute ein Cookie selbst basteln und anderer Leute Daten auslesen).

      In einer WG benutzen verschiedene Personen denselben E-Mail-Provider oder Ebay und lassen den Einlogstatus vom Browser speichern

      Und kluge Programmierer sorgen dafür, dass vor wichtige Funktionen im Webangebot in jedem Fall, egal ob dauereingeloggt oder nicht, eine weitere Passwortabfrage kommt (was natürlich nichts nützt, wenn das Passwort im Browser gespeichert ist).

      Genau das war meine Frage. Also auf jeden Fall eine Paßwortabfrage, ob dauereingeloggt oder nicht. Irgendwie wird das Dauer-eingeloggt-sein damit sinnlos ..

      (was natürlich nichts nützt, wenn das Passwort im Browser gespeichert ist).

      Klar, soviel Verantwortung muß der User schon selbst übernehmen.

      1. Keine Frage zur Sicherheit, sondern zum Umgang mit Session-Cookies: Angenommen, Cookies sind abgeschaltet. Der User schickt das Einlogg-Formular ab. Das Skript prüft, ob ein Cookie gesetzt wurde. Wenn ja, findet die Überprüfung der Zugangsdaten statt. Wenn nein, wird der User auf die fehlende Cookie-Unterstützung hingewiesen und das Formular erneut ausgegeben. Der User schaltet Cookies ein und sendet das Formular ab. Nun wurde aber kein Cookie gesetzt (wenn der User das Formular nicht selbst nach Cookie-Einschaltung aktualisiert hat). Die Folge ist: Das Skript bemängelt wieder nicht eingeschaltete Cookies. Kann man das umgehen?

      Ja, durch einen Zwischenschritt. Nach Absenden des Formulars wird der Inhalt geprüft, dann (bei korrekten Zugangsdaten) die Sitzung aufgemacht (nicht schon vor Schritt 1) und eine Zwischenseite ausgegeben, die a) den Keks setzt und b) automatisch zu einer Keksprüfseite weiterleitet, die ihrerseits die Keksexistenz prüft und je nach Ergebnis zur Kein-Keks-Korrekturklage oder zur gewünschten Inhaltsseite weiterleitet. Die Datenübergabe zwischen den einzelnen Schritten erfolgt durch Übermittlung der Sitzungskennung als URL-Parameter.

      Daran hatte ich auch gedacht, mit header() weiterzuleiten. Ich dachte nur, es gäbe eine Alternative ohne Weiterleitung.

      Diese Vorgehensweise hat unter Umständen gleichzeitig den Vorteil, dass man Leute, die kein Cookie brauchen, gar nicht erst mit Cookies belästigt.

      1. Nein, die üblicherweise richtige Konfiguration vorausgesetzt. Der Webserver gibt den Quellcode von Skripten generell nicht aus,

        Ist die Konfiguration über allow_url_fopen einzustellen?

        Nein, mit "richtiger Konfiguration" meine ich, dass der (Ziel-) Webserver PHP-Skripte als solche erkennen und ausführen muss. Das ist bei eigentlich jedem Webserver der Fall, sonst würden PHP-Skripte ja nicht funktionieren, deshalb "üblicherweise".

        Wenn also deine PHP-Skripte im Browser nicht als Quellcode angezeigt werden, dann kann sie auch niemand sonst mittels HTTP auslesen. fopen("http:…") macht genau das Gleiche wie ein Webbrowser. Ähnliches gilt füt FTP: Ist der FTP-Zugang passwortgesichert, kann niemand, der das Passwort nicht kennt, per FTP den Quellcode auslesen. fopen("ftp:…") macht genau das Gleiche wie ein FTP-Client.

        Cookies kannst du dir im Grunde einfach als Dateien vorstellen, jede Datei hat einen Namen, mit dem sie angesprochen wird, und einen Inhalt. Auf verschiedenen Rechnern kann es Dateien mit dem gleichen Namen, aber unterschiedlichem Inhalt geben.

        Ja, das weiß ich. Das Problem ist ja nur, standardmäßig wird das Session-Cookie als PHPSESSID abgelegt, wenn das so in session.name in der php.ini konfiguriert wurde. Demnach könnte ja kein Cookie für einen zweiten Benutzer abgelegt werden.

        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? Und was im Browser von deinem Nachbarn gespeichert ist, interessiert deinen Browser nicht.

        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.

        Daran hatte ich auch gedacht, mit header() weiterzuleiten. Ich dachte nur, es gäbe eine Alternative ohne Weiterleitung.

        Du könntest versuchen, bereits mit der Ausgabe des Formulars ein Cookie zu setzen. Ist es beim Empfang der Formulardaten (=Loginversuch) nicht zu sehen (=hat der Benutzer Cookies abgeschaltet), könntest du nur die Fehlermeldung ausgeben, nicht das Formular. Setzt du noch einen Verweis dazu, der auf das Formular zeigt ("Hier erneut einloggen, sobald Cookies eingeschaltet"), stehen die Chancen IMHO recht gut, dass der Benutzer darüber das Formular wieder aufruft und somit seinen Keks verpasst bekommt.

        1. Wenn also deine PHP-Skripte im Browser nicht als Quellcode angezeigt werden, dann kann sie auch niemand sonst mittels HTTP auslesen. fopen("http:…") macht genau das Gleiche wie ein Webbrowser.

          Genau das wollte ich wissen!

          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? Und was im Browser von deinem Nachbarn gespeichert ist, interessiert deinen Browser nicht.

          Na ja, siehe das fiktive Szenario, mehrere Personen in einer WG oder in einem Betrieb am selben Rechner greifen auf dieselbe Site zu ...

          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. Firefox hat Sitzungs-Cookies nur im Speicher, legt ihn nicht irgendwo in einer Datei ab. Ich vermute, bei anderen Browsern wird das genauso sein.

          Ob oder wie man mit session_set_cookie_params() und session_start() einen dauerhaften Cookie ablegen kann, muß ich erst noch schauen.

          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?

          Daran hatte ich auch gedacht, mit header() weiterzuleiten. Ich dachte nur, es gäbe eine Alternative ohne Weiterleitung.

          Du könntest versuchen, bereits mit der Ausgabe des Formulars ein Cookie zu setzen. Ist es beim Empfang der Formulardaten (=Loginversuch) nicht zu sehen (=hat der Benutzer Cookies abgeschaltet), könntest du nur die Fehlermeldung ausgeben, nicht das Formular. Setzt du noch einen Verweis dazu, der auf das Formular zeigt ("Hier erneut einloggen, sobald Cookies eingeschaltet"), stehen die Chancen IMHO recht gut, dass der Benutzer darüber das Formular wieder aufruft und somit seinen Keks verpasst bekommt.

          So hatte ich das bisher gelöst. Das ergab aber ein neues Problem: 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. Der User soll sich alos neu einloggen. Nach dem Absenden des Formulars ist aber kein Cookie vorhanden, obwohl Cookies eingeschaltet sind. Das Cookie wurde ja zuvor manuell gelöscht. Der User landet nach der Abfrage if ( isset($_POST['login']) && count($_COOKIE) == 0 ) $fehler_modus = "cookies_ausgeschaltet"; bei der Aufforderung, Cookies einzuschalten. Ist ein Teufelskreis ...

          Man könnte höchstens das Hidden-Feld 'login' beim Timeout anders benennen. Dann könnte das Skript die Fälle unterscheiden. Muß ich mal versuchen, aber wer weiß, was daraus wieder für neue Probleme resultieren.

          1. 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.

            1. 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?

              1. 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.

                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."

                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.

                1. Nein, schon richtig, aber die Frage wird interessant, wenn die Sitzung-Cookies dauerhaft abgelegt werden.

                  Da hast du in der Tat recht.

                  Anderes Szenario: keine dauerhaften Cookies, aber User (nicht in WG, da hast Du recht, daß die nicht gleichzeitig am selben Rechner sind, sondern in einem Betrieb) greifen gleichzeitig zu. Muß dann je Nutzer ein anderer Cookie verwendet werden mit verschiedenem Cookie-Namen?

                  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.

                  Hm, auch dann können verfolgende Cookies von unterschiedlichen Websites, die mit einem Dienst in der Art von doubleclick auf ein gemeinsames Cookie zugreifen können, Dein Surfverhalten überwachen, solange Du nicht den Browser schließt. Ich benutze z. B. exzessiv Tabs, ohne permanent die Browser-Instanz(en) (neben Tabs habe ich meist auch mehrere Browser-Fenster offen) zu schließen. Deshalb wären mir auch temporäre Cookies zu unsicher. Es reicht schon die staatliche Überwachung, die immer weiter um sich greift. Dann nicht auch noch kommerzielle Überwachung.

                  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.

                  Toller Tip, kannte ich noch nicht. Das Design ist zwar stark von Google abgekupfert (=geklaut), aber wat solls. So findet man sich schnell zurecht. Werde ich zukünftig auf jeden Fall öfter benutzen.

                  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.

                  Also werden Zugriffe auf den localhost nach google-analytics.com umgeleitet!? Das wäre ja schon kriminell! Wie schon gesagt, jeder Idi nutzt völlig bedenkenlos Google, ohne über die Konsequenzen nachzudenken, was das Verschwinden anderer Suchmaschinen bedeutet.

                  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.

                  Ok, dann kann ich mir das wirklich sparen.

                  1. Anderes Szenario: keine dauerhaften Cookies, aber User (nicht in WG, da hast Du recht, daß die nicht gleichzeitig am selben Rechner sind, sondern in einem Betrieb) greifen gleichzeitig zu.

                    Auch in einem Betrieb wird doch jeder Rechner nur von einem Benutzer zur Zeit in Beschlag gehalten. Es ist schon wegen der nur einmal vorhandenen Eingabemöglichkeiten Maus und Tastatur undenkbar, dass zwei Leute gleichzeitig denselben Browser benutzen und sich damit in demselben Cookie-Gültigkeitsbereich bewegen.

                    Schwierigkeiten gibt es, egal ob statische oder temporäre Cookies (oder URL-Parameter), nur, wenn ein Benutzer vergisst, sich auszuloggen, und den Browser in diesem Zustand an den nächsten Benutzer weitergibt. Das kann sicher vorkommen, gegen solche Dummheit wächst auf Seiten des Webserverbetreibers aber nur das Pflänzchen "Sitzungsende nach 10 Minuten Inaktivität", welches sich zudem eher mit den Symptomen als der Krankheit befasst.

                    lasse ich stattdessen das Cookie-Verfallsdatum vom Browser automatisch auf das Browserende begrenzen.

                    Hm, auch dann können verfolgende Cookies von unterschiedlichen Websites, die mit einem Dienst in der Art von doubleclick auf ein gemeinsames Cookie zugreifen können, Dein Surfverhalten überwachen, solange Du nicht den Browser schließt.

                    Gut, die Verfolgbarkeit mit temporären Cookies steht und fällt natürlich mit der Browsernutzung. Dass bei mir mal der Browser länger als ein paar Stunden am Stück aktiv ist, kommt eher selten vor. Und weil mir mein 17"-Bildschirm merkwürdigerweise bisweilen schon zu klein ist (auf meinem ersten Rechner ließ sich mit 640×256 Pixeln fein wurschteln), mache ich eher ein Fenster zu viel als zu wenig dicht, was auch für den Browser öftere Neustarts bedeutet.

                    127.0.0.1       localhost google-analytics.com ssl.google-analytics.com www.google-analytics.com

                    Also werden Zugriffe auf den localhost nach google-analytics.com umgeleitet!?

                    Nein, die Hosts-Datei dient dazu, Domainnamen in IP-Adressen umzuwandeln, sie ist sozusagen die kleine Schwester des DNS-Servers, wird aber vor letzterem befragt. Mit ihr lässt sich somit die heimische Sicht auf das DNS zurechtbiegen.
                    Am Anfang einer Zeile steht die IP-Adresse (hier: das eigene System, 127.0.0.1), darauf folgen sämtliche Domainnamen, die zu dieser IP gehören.
                    Es ist also genau andersrum, Zugriffe auf "google-analytics.com" etc. werden wie jene auf "localhost" nach 127.0.0.1, also den eigenen Rechner geleitet (und laufen dort mangels Webserver ins Leere).

                    Damit ließen sich auch Werbeserver von DoubleClick & Co. aussperren, aber das sehe ich nicht nun wieder gar nicht gerne, weil mir dann Einnahmen flöten gehen - wer meine mit viel Mühe und Liebe erstellten Webseiten nutzt, darf mir auch gerne dafür einen kleinen Obulus überlassen. Fair geht vor :-)

                    1. Anderes Szenario: keine dauerhaften Cookies, aber User (nicht in WG, da hast Du recht, daß die nicht gleichzeitig am selben Rechner sind, sondern in einem Betrieb) greifen gleichzeitig zu.

                      Auch in einem Betrieb wird doch jeder Rechner nur von einem Benutzer zur Zeit in Beschlag gehalten. Es ist schon wegen der nur einmal vorhandenen Eingabemöglichkeiten Maus und Tastatur undenkbar, dass zwei Leute gleichzeitig denselben Browser benutzen und sich damit in demselben Cookie-Gültigkeitsbereich bewegen.

                      Schon klar. Ich meinte, wenn verschiedene Rechner parallel auf eine Website zugreifen. Kriegen die nicht alle dieselbe IP nach außen, und nur innerhalb des Intranets haben die Rechner verschiedene lokale IPs? Ich kenne mich da nicht so besonders aus.

                      Schwierigkeiten gibt es, egal ob statische oder temporäre Cookies (oder URL-Parameter), nur, wenn ein Benutzer vergisst, sich auszuloggen, und den Browser in diesem Zustand an den nächsten Benutzer weitergibt. Das kann sicher vorkommen, gegen solche Dummheit wächst auf Seiten des Webserverbetreibers aber nur das Pflänzchen "Sitzungsende nach 10 Minuten Inaktivität", welches sich zudem eher mit den Symptomen als der Krankheit befasst.

                      Richtig.

                      lasse ich stattdessen das Cookie-Verfallsdatum vom Browser automatisch auf das Browserende begrenzen.

                      Hm, auch dann können verfolgende Cookies von unterschiedlichen Websites, die mit einem Dienst in der Art von doubleclick auf ein gemeinsames Cookie zugreifen können, Dein Surfverhalten überwachen, solange Du nicht den Browser schließt.

                      Gut, die Verfolgbarkeit mit temporären Cookies steht und fällt natürlich mit der Browsernutzung. Dass bei mir mal der Browser länger als ein paar Stunden am Stück aktiv ist, kommt eher selten vor. Und weil mir mein 17"-Bildschirm merkwürdigerweise bisweilen schon zu klein ist (auf meinem ersten Rechner ließ sich mit 640×256 Pixeln fein wurschteln), mache ich eher ein Fenster zu viel als zu wenig dicht, was auch für den Browser öftere Neustarts bedeutet.

                      »»

                      In Zeiten erschwinglicher Flatrates kommt es bei mir öfters vor, daß Browser-Instanzen stundenlang geöffnet sind, ohne die Verbindung ins Web zu kappen. Ist natürlich jedem seine eigene Sache, wie er die Sicherheit handhabt. Ich halte es nur für falsch, Leuten ohne Hintergrundwissen einzureden, temporäre Cookies seien sicher. Das stimmt einfach nicht. Wer keine Ahnung hat, wie das Internet funktioniert, sollte gar keine Cookies akzeptieren und nur selbst in die White-List eingetragene zulassen.

                      Damit ließen sich auch Werbeserver von DoubleClick & Co. aussperren, aber das sehe ich nicht nun wieder gar nicht gerne, weil mir dann Einnahmen flöten gehen - wer meine mit viel Mühe und Liebe erstellten Webseiten nutzt, darf mir auch gerne dafür einen kleinen Obulus überlassen. Fair geht vor :-)

                      Gibt es keine anderen Möglichkeiten, Geld mit Deinen Seiten zu verdienen, als ausgerechnet Doubleclick? Würde nur anonym Nutzerverhalten protokolliert, z. B. für Werbeeinblendungen, Messungen von Marketingaktionen usw., könnte man noch darüber hinwegsehen. Leider sieht das Ebay (oder auch Amazon usw.) anders. Ich will nicht wissen, was Doubleclick alles bei Ebay mitloggt. Für welche Auktionen ich mich interessiere, geht aber eigentlich keinen was an. Und ich will auch nicht jahrelang von Amazon mit Produktangeboten belästigt werden, nur weil ich einmal zu einem Thema ein Buch gekauft habe.

                      In den USA muß, soweit ich weiß, Ebay auf Verlangen der Regierung sämtliche mitgeloggten Benutzerdaten (Käufe, was Besucher sich angeschaut haben usw.) herausgeben. Der gläserne Surfer ist da schon längst Realität.

                      1. Auch in einem Betrieb wird doch jeder Rechner nur von einem Benutzer zur Zeit in Beschlag gehalten.

                        Schon klar. Ich meinte, wenn verschiedene Rechner parallel auf eine Website zugreifen. Kriegen die nicht alle dieselbe IP nach außen

                        Unerheblich. Eine Sitzung wird nicht anhand der IP zugeordnet, sondern anhand der Kennung (SID), und die ist per Definition immer eindeutig. Punkt. Die Kennung hängt in keiner Weise mit der Verbindung zusammen, sondern nur mit dem anfordernden Browser und dem ausgebenden Server.

                        Du könntest auch auf deinem Rechner parallel einmal mit Firefox und einmal mit Opera zeitgleich auf dieselbe Webseite zugreifen und wirst trotzdem zwei verschiedene Kennungen und damit zwei unabhängige Sitzungen erhalten, für jeden Browser eine eigene.

                        Damit ließen sich auch Werbeserver von DoubleClick & Co. aussperren, aber das sehe ich nicht nun wieder gar nicht gerne, weil mir dann Einnahmen flöten gehen - wer meine mit viel Mühe und Liebe erstellten Webseiten nutzt, darf mir auch gerne dafür einen kleinen Obulus überlassen. Fair geht vor :-)

                        Gibt es keine anderen Möglichkeiten, Geld mit Deinen Seiten zu verdienen, als ausgerechnet Doubleclick?

                        Doubleclick war nur ein Beispiel, nichtsdestotrotz hat man auf den Adserver der großen Kampangenbetreiber keinen Einfluss. Und nur vom Geld kleiner Werbetreibender kann ich nicht leben.

                        Im Web über Abogebühren, gänzlich ohne Werbung tragfähige Einnahmen zu erzielen, ist zudem für die allermeisten Seitenbetreiber eher ein Wunschtraum, dazu ist wohl der Egoismus im Netz zu beherrschend (ich biete Werbefreiheit gegen Abo an, die Resonanz ist sehr gering).

                        1. Auch in einem Betrieb wird doch jeder Rechner nur von einem Benutzer zur Zeit in Beschlag gehalten.

                          Schon klar. Ich meinte, wenn verschiedene Rechner parallel auf eine Website zugreifen. Kriegen die nicht alle dieselbe IP nach außen

                          Unerheblich. Eine Sitzung wird nicht anhand der IP zugeordnet, sondern anhand der Kennung (SID), und die ist per Definition immer eindeutig. Punkt. Die Kennung hängt in keiner Weise mit der Verbindung zusammen, sondern nur mit dem anfordernden Browser und dem ausgebenden Server.

                          Ich habe es jetzt verstanden. Der Browser sendet das Cookie mit der SID. Andere Verbindungsdaten interessieren nicht, weil das gesendete Cookie einzigartig ist.

                          Du könntest auch auf deinem Rechner parallel einmal mit Firefox und einmal mit Opera zeitgleich auf dieselbe Webseite zugreifen und wirst trotzdem zwei verschiedene Kennungen und damit zwei unabhängige Sitzungen erhalten, für jeden Browser eine eigene.

                          Das stimmt, weil es zwei verschiedene Browser sind. Wenn Du zweimal mit dem gleichen Browser einloggst, wird, egal ob temporäre oder dauerhafte Sitzungscookies, die erste Sitzung von der zweiten überschrieben. D.h. der erste User hat plötzlich Zugriff auf die Daten des zweiten Nutzers. Hab´s gerade ausprobiert, ist tatsächlich so, wie erwartet.

                          Für das Szenario: mehrere Leute NACHEINANDER am Rechner, DAUERHAFTE Sitzungscookies müßte also der Name des Cookies variabel sein, oder es ist kein dauerhaftes Eingeloggt sein (ohne Paßworteingabe) möglich. Ich weiß aber nicht, inwieweit das überhaupt geht. Das wäre ja pro Person ein Cookie, und, soweit ich weiß, ist pro Domäne nur ein Cookie erlaubt.