PHP Session-Sicherheit

  • Welche Richtlinien gelten für die Aufrechterhaltung der Sicherheit für verantwortungsbewusste Sitzungen mit PHP? Es gibt Informationen im gesamten Web und es ist an der Zeit, dass alles an einem Ort gelandet ist!

    04 May 2012
    mattytommoSkooz
13 answers
  • Um die Sicherheit Ihrer Sitzung zu gewährleisten, müssen Sie Folgendes tun:

    1. Verwenden Sie SSL, wenn Sie Benutzer authentifizieren oder vertrauliche Vorgänge ausführen .
    2. Generieren Sie die Sitzungs-ID immer dann neu, wenn sich die Sicherheitsstufe ändert (z. B. Anmelden). Sie können sogar die Sitzungs-ID bei jeder Anforderung neu generieren.
    3. Sitzen Sie Zeitüberschreitung
    4. Verwenden Sie keine Register-Globals
    5. Authentifizierungsdetails auf dem Server speichern. Senden Sie also keine Details wie den Benutzernamen im Cookie.
    6. Überprüfen Sie $_SERVER['HTTP_USER_AGENT']. Dies fügt eine kleine Hürde für Session-Hijacking hinzu. Sie können auch die IP-Adresse überprüfen. Dies verursacht jedoch Probleme für Benutzer, deren IP-Adresse aufgrund von Lastausgleich bei mehreren Internetverbindungen usw. geändert wird (dies ist in unserer Umgebung der Fall).
    7. Sperren Sie den Zugriff auf die Sitzungen in der Datei System oder benutzerspezifische Sitzungsbehandlung verwenden
    8. Für sensible Vorgänge müssen Sie angemeldete Benutzer dazu auffordern, ihre Authentifizierungsdetails erneut anzugeben.
    06 June 2012
    grom
  • Eine Richtlinie ist, die session_regenerate_id bei jeder Änderung der Sicherheitsstufe einer Sitzung aufzurufen. Dies hilft, Sitzungsentführungen zu verhindern.

    02 August 2008
    saint_groceon
  • Ich denke, eines der Hauptprobleme (das in PHP 6 angesprochen wird) ist register_globals. Eine der Standardmethoden zur Vermeidung von register_globals ist die Verwendung der Arrays $_REQUEST, $_GET oder $_POST.

    Die "richtige" Methode es ist (ab 5.2, obwohl es ein wenig fehlerhaft ist, aber stabil ab 6, was bald kommen wird) durch Filter .

    Statt also:

     $username = $_POST["username"];
     

    würden Sie tun:

     $username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING);
     

    oder auch nur:

     $username = filter_input(INPUT_POST, 'username');
     
    04 May 2012
    mattytommoSkooz
  • Meine zwei (oder mehr) Cent:

    • Vertrauen Sie niemandem
    • Filtern Sie die Eingabe, escape Ausgabe (Cookie, Sitzungsdaten sind auch Ihre Eingabe)
    • Vermeiden Sie XSS (halten Sie Ihren HTML-Code in Ordnung, sehen Sie sich PHPTAL oder HTMLPurifier )
    • Tiefe Verteidigung
    • Keine Daten freigeben

    Zu diesem Thema gibt es ein winziges, aber gutes Buch: Grundlegende PHP-Sicherheit von Chris Shiflett .

    Grundlegende PHP-Sicherheit http://shiflett.org/images/essential-php-security-small.png

    Auf der Startseite des Buches finden Sie einige interessante Codebeispiele und Beispielkapitel.

    Sie können die Technik verwenden oben erwähnt (IP und UserAgent), hier beschrieben: wie um Identitätsdiebstahl zu vermeiden

    06 April 2010
    takeshin
  • Dieses Dokument zur Sitzungsfixierung enthält sehr gute Hinweise auf mögliche Angriffe . Siehe auch Seite zur Sitzungsfixierung in Wikipedia .

    06 March 2009
    raspi
  • Die Verwendung von IP-Adressen ist meiner Meinung nach nicht wirklich die beste Idee. Zum Beispiel; Mein Büro hat zwei IP-Adressen, die je nach Auslastung verwendet werden, und wir stoßen ständig auf Probleme mit der Verwendung von IP-Adressen.

    Stattdessen habe ich mich dazu entschieden, die Sitzungen in einer separaten Datenbank für die Domänen auf meinen Servern zu speichern. Auf diese Weise hat niemand im Dateisystem Zugriff auf diese Sitzungsinformationen. Das war wirklich hilfreich bei phpBB vor 3.0 (seitdem ist das Problem behoben), aber ich denke immer noch eine gute Idee.

    07 August 2008
    Eric Lamb
  • php.ini

     session.cookie_httponly = 1
    change session name from default PHPSESSID
     

    eq Apache hinzufügen Header:

     X-XSS-Protection    1
     
    13 October 2011
    user956584
  • Das ist ziemlich trivial und offensichtlich, aber stellen Sie sicher, dass Sie session_destroy nach jeder Verwendung verwenden. Dies kann schwierig zu implementieren sein, wenn der Benutzer sich nicht explizit abmeldet. Daher kann ein Zeitgeber dafür festgelegt werden.

    Hier ist ein guter Tutorial zu setTimer () und clearTimer ().

    02 August 2008
    helloandreDrahcir
  • Das Hauptproblem bei PHP-Sitzungen und der Sicherheit (neben dem Hijacking von Sitzungen) hängt von der Umgebung ab, in der Sie sich befinden. Standardmäßig speichert PHP die Sitzungsdaten in einer Datei im temporären Verzeichnis des Betriebssystems. Ohne besondere Überlegungen oder Planungen ist dies ein weltweit lesbares Verzeichnis, sodass alle Ihre Sitzungsinformationen für alle Personen mit Zugriff auf den Server öffentlich sind.

    Zum Verwalten von Sitzungen über mehrere Server. An diesem Punkt ist es besser, PHP auf vom Benutzer behandelte Sitzungen umzustellen, in denen die bereitgestellten Funktionen in CRUD (Erstellen, Lesen, Aktualisieren, Löschen) der Sitzungsdaten aufgerufen werden. An diesem Punkt könnten Sie die Sitzungsinformationen in einer Datenbank oder einer Memcache-ähnlichen Lösung speichern, sodass alle Anwendungsserver auf die Daten zugreifen können.

    Das Speichern Ihrer eigenen Sitzungen kann auch von Vorteil sein, wenn Sie dies tun Sie befinden sich auf einem gemeinsam genutzten Server, da Sie sie in der Datenbank speichern können, und Sie haben oft mehr Kontrolle über das Dateisystem.

    03 August 2008
    John Downey
  • Ich habe meine Sitzungen so eingerichtet -

    auf der Anmeldeseite:

     $_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR']);
     

    (auf einer Konfigurationsseite definierte Phrase)

    und dann in der Kopfzeile des Restes der Site:

     session_start();
    if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR'])) {       
        session_destroy();
        header('Location: http://website login page/');
        exit();     
    }
     
    20 July 2011
    Chad