Frage Korrekte Art, Sitzungen in PHP zu verwalten?


Ich richte derzeit ein Authentifizierungssystem ein. Mein derzeitiges Layout ist es, seine Email von der $_POST, md5 sein Passwort, und überprüfen Sie die Datenbank gegen seine E-Mail und sein Passwort. Wenn es passt, benutze ich session_startund ich fange an, Daten in der $_SESSION variabel, so:

 $_SESSION['uid'] = $uid;
 $_SESSION['first_name'] = $first_name;

Und auf jeder Seite der Website würde ich eine einfache Überprüfung vornehmen

isset($_SESSION['uid']);

Wenn nicht, Umleitung zur Indexseite, wenn ja, laden Sie die Seite.

Mache ich das richtig? Ist das sicher genug? Wie leicht ist es für jemanden, diese Daten zu fälschen?

Jemand sagte mir, dass ich eine Tabelle mit der E-Mail-Adresse des Benutzers und seiner Sitzungs-ID erstellen und diese verwenden sollte, um die Dinge zu verwalten ... Ich bin ziemlich verwirrt geworden - wie würde das helfen?

Könnte jemand das klären? Wie kann man die Authentifizierung mit PHP-Sitzungen richtig verwalten?

Vielen Dank.


36
2018-06-08 09:34


Ursprung


Antworten:


Sicherheitsupdate: seit 2017-10-23: Der Rat in dieser Antwort, während von historischer Bedeutung, ist völlig unsicher. Man sollte niemals md5 benutzen, um ein Passwort zu hashen, weil es so leicht brutal erzwungen wird. Sehen diese Antwort darüber, wie man das eingebaute Passwort password_ * api zum Hashing und Verifizieren von Passwörtern verwendet.


Ich habe mich früher mit Anmelde- / Authentifizierungssystemen beschäftigt, und ich finde bei dieser Methode einige Mängel:

  • Sie "md5 sein Passwort, und überprüfen Sie die Datenbank" - das bedeutet, dass, wenn eine Person Zugriff auf die Datenbank hat, kann er erkennen, wer die gleichen Passwörter hat!

NACHTRAG (19 Sep 2015) * Schau dir das an Verknüpfung. Es erklärt alle Grundlagen, die Ansätze, die Sie ergreifen könnten, warum Sie diese Ansätze verwenden sollten und gibt Ihnen auch Beispiel-PHP-Code. Wenn es zu lange ist, um zu lesen, gehen Sie einfach zum Ende, greifen Sie den Code und setzen Sie sich!

Besserer Ansatz: um md5 zu speichern username+password+email+salt in der Datenbank Salz- zufällig sein und zusammen mit dem Benutzerdatensatz gespeichert werden.

  • Die Verwendung der 'uid' direkt in den Session-Variablen kann sehr riskant sein. Bedenken Sie Folgendes: Mein Freund ist von meinem Browser aus angemeldet und er geht auf ein Leck. Ich überprüfe schnell, welche Cookies in seinem Browser eingestellt sind und entziffere seine 'uid'. Jetzt besitze ich ihn!

Besserer Ansatz: um eine zufällige sessionid zu generieren, wenn der Benutzer sich erfolgreich anmeldet, und speichern Sie diese Sitzung ID in der $_SESSION[] Array. Sie müssen auch die Sitzungs-ID mit seiner Benutzer-ID verknüpfen (mithilfe der Datenbank oder memcached). Vorteile sind:

  1. Sie können sogar eine Sitzungs-ID an eine bestimmte IP-Adresse binden, so dass die Sitzungs-ID nicht missbraucht werden kann, selbst wenn sie erfasst wird
  2. Sie können eine ältere Sitzungs-ID ungültig machen, wenn sich der Benutzer von einem anderen Standort aus anmeldet. Wenn sich mein Freund von seinem eigenen Computer aus anmeldet, wird die Sitzungs-ID auf meinem Computer automatisch ungültig.

EDIT: Ich habe immer Cookies manuell für meine Session-Handhabung verwendet. Dies hilft mir, die JavaScript-Komponenten meiner Web-Apps leichter zu integrieren. Möglicherweise benötigen Sie in Zukunft in Ihren Apps dasselbe.


42
2018-06-08 09:49



Es ist nichts falsch daran, dies zu tun

isset($_SESSION['uid']);

Die Sitzungsdaten werden nicht an den Benutzer übertragen, sie werden auf dem Server gespeichert (oder dort, wo der Sitzungshandler sie speichert). Was an den Benutzer übertragen wird, ist die Sitzungs-ID, bei der es sich um eine zufällige Zeichenfolge handelt, die von PHP generiert wird. Diese kann natürlich gestohlen werden, weil sie an den Benutzer gesendet wird.

Es sollte deutlich darauf hingewiesen werden, dass das zufällige Speichern einer Zeichenfolge in der Datenbank und der Benutzersitzung und das anschließende Identifizieren des Benutzers die Sitzung nicht sicherer macht, wenn der Angreifer die Sitzung erhält, die den Benutzer noch beeinträchtigt.

Was wir jetzt diskutieren, ist Session-HijackingVielleicht denkst du, dass du einfach die IP-Adresse in der Sitzung speichern und überprüfen kannst, ob die IP aus der Anfrage stammt und damit erledigt ist. Aber es ist oft nicht so einfach, ich habe mich vor kurzem verbrannt, als wir in einer großen Web-Anwendung einen Hash des User Agent + IP-Adresse in der Sitzung gespeichert und dann überprüft haben, dass sie bei 99% der Benutzer übereinstimmten das hat gut funktioniert. Wir haben jedoch Anrufe von Leuten bekommen, die feststellten, dass sie ständig ohne Erklärung ausgeloggt wurden. Wir haben die Session-Hijacking-Prüfungen protokolliert, um zu sehen, was vor sich ging, und festgestellt, dass diese Leute auf einer IP eingehen und ihre Sitzung auf einer anderen fortsetzen würde. Dies war kein Entführungsversuch, sondern wie ihr Proxy-Server Als Ergebnis haben wir unseren Session - Hijacking - Code geändert, um den Klasse der IP-Adresse und von dort herauszufinden, den Netzwerk-Teil der IP-Adresse und speichern Sie nur die Teile der IP-Adresse, das ist etwas weniger sicher in dieser Session Hijacking könnte theoretisch aus dem gleichen Netzwerk kommen, sondern verursacht alle unsere falschen Positive weggehen.


26
2018-06-08 12:57



Ich muss das hinzufügen. Wenn Sie das "MD5 das Passwort, dann überprüfen Sie die Datenbank" -Methode, schlägt dies vor, dass das Passwort in einem einzigen MD5-Hash gespeichert wird. Dies ist nicht länger eine Standardmethode zum Speichern von Hash-Passwörtern.

Ich fand diesen Link sehr informativ: http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard


3
2017-09-16 20:51



Ich bin nicht 100% dabei, aber ich denke, dass es möglich ist, die Sitzung zu schmieden, wenn jemand wirklich wollte!

Ich denke, das Speichern der Sitzungs-ID in einer Tabelle ist der sicherste Weg, dies zu tun.

Ich habe mich in letzter Zeit ein wenig damit beschäftigt, aber ich bin mir nicht sicher, interessiert, was Best Practice ist!

Hier sind ein paar Ressourcen zu betrachten

http://www.sitepoint.com/article/php-security-blunders/

http://www.phpeasystep.com/workshopview.php?id=6


-3
2018-06-08 09:43