Ich weiß, das wurde Milliarden von Malen gefragt, aber ich bin super paranoid / OCD über die Sicherheit meiner Codierung. Ich arbeite an einem kleinen Projekt. Die Sitzungsdaten enthalten nur:
user_id 1
Benutzername Mein Benutzername
logged_in true
csrf_token 87cc51ee94178df79cccce2aebc45d53 p>
Hier ist mein Code. Ist es sicher genug, um es auf einem kleinen CMS zu verwenden?
%Vor%Dann rufen Sie die Sitzungen auf:
%Vor% Zusatzinfo
Ich werde die Sitzungsdaten verwenden, um zu überprüfen, ob der Benutzer Berechtigungen hat, etwas zu tun. Beispiel: if ( user_has_perm( $_SESSION['user_id'] ) )
Vielen Dank für Ihre Hilfe im Voraus.
Sitzungssicherheitsrisiken ergeben sich aus drei verschiedenen Möglichkeiten:
Vorhersage würde bedeuten, dass jemand, der nicht der Benutzer ist, für den die Sitzung erstellt wurde, ihre Sitzungs-ID erraten hat. Die Chancen dafür sind fast 0, obwohl sie wachsen, wie mehr Benutzer die Website gleichzeitig nutzen.
Mit Ihrem Code würden Sie dieses Risiko sogar noch senken, weil es nur funktionieren würde, wenn der Angreifer den Benutzeragenten und die IP der vorhergesagten Sitzung teilen würde. Aber der Unterschied ist in diesem Fall trivial.
Die Fixierung würde bedeuten, dass ein Angreifer eine Sitzung erstellen und dann einen anderen Benutzer zwingen kann, ihre Sitzung zu verwenden. In diesem Fall würde es abhängen: Wenn der Angreifer weiß, dass Sie es tun, und sie den Benutzeragenten und die IP des Clients fälschen, können sie die Sitzung fixieren. Oder wenn sie ip und user agent teilen.
Und schließlich haben wir Session-Hijacking, wahrscheinlich die gängigste Methode der drei. In diesem Fall würde ein Angreifer irgendwie Zugriff auf die Sitzungs-ID eines gültigen angemeldeten Benutzers erhalten und ihn dann verwenden, um sich bei seinem Konto anzumelden. Wie bei der vorherigen Methode würde dies nur für sie funktionieren, wenn sie wissen, dass Sie den ip- und user-agent überprüfen und die gleichen wie der Benutzer gefälscht haben. Die Technik, die Sie verwenden, ist nicht einzigartig und einige Angreifer fälschen sie nur für den Fall.
Ist das gesagt, ist es sicher? Ja und nein
Wenn Sie von Sicherheit besessen sind, lautet die Antwort immer die gleiche: SSL verwenden
Wenn Ihr Code nicht Open Source ist, ist fast alles, was Sie tun, das das Verhalten der PHP-Sitzungen ändert, sicher genug.
Die einzige Ausnahme wären wirklich beliebte Websites, die die Aufmerksamkeit von Hackern auf sich ziehen.
Es gibt eine sehr gute Dokumentation zu diesem Thema zur Verfügung:
Ich bin kein Sicherheitsexperte. Ich bezweifle jedoch demütig, dass Ihre Sicherheitsmaßnahmen erhebliche Vorteile bringen werden.
Wenn es jemanden gibt, der die Sitzungs-ID Ihrer Benutzer stehlen kann, zum Beispiel durch Abhören eines unverschlüsselten drahtlosen Netzwerks, kann er womöglich auch den Benutzernamen und das Passwort stehlen, die Ihre Benutzer bei der Authentifizierung an Ihren Server senden. Sobald er die Zugangsberechtigungen hat, kann sich der Angreifer am Tag danach oder eine Woche später einloggen und wird seine "sichere" - und 100% gültige - Sitzung zum Spielen haben.
Ich glaube, dass es keine Sitzungssicherheit ohne Kanalsicherheit gibt. Wenn Sie SSL verwenden , stellen Sie sicher, dass die Sitzungs-ID nur über Cookies gesendet wird (Sie tun dies bereits) und Ihre Sitzungen laufen bald ab. Ich glaube, Sie sind einigermaßen sicher und sicherer als diese Durchsetzung auf einem unsicheren Kanal.
Erstens haben Sie einen Fehler im Code für die Neugenerierung der Sitzung. Das folgende if wird immer als wahr ausgewertet:
%Vor% Wenn $rand nicht 1 ist, wird true zurückgegeben. Wenn $rand ist 1, dann ist es nicht drei, und es gibt wahr zurück. Wahrscheinlich wollten Sie hier ein and verwenden.
Zweitens müssen Sie die user_ip - oder user_agent -Zeichenfolgen nicht mit MD5 verknüpfen. Wenn jemand direkt auf die Sitzungsdaten auf Ihrem Server zugreifen kann, sind Sie so tief darin, dass die Daten Sie nicht retten.
Erklärung: Wie SDC und crush in den Kommentaren zeigen, ist MD5 gut für das Hashing von Passwörtern , wenn Sie es mit einem Salz hashen. Dies bedeutet, dass die Kennwörter Ihres Benutzers im Allgemeinen immer noch sicher sind, selbst wenn ein SQL Injection-Angriff erfolgreich ist und Ihre Datenbank der Welt ausgesetzt ist. Wenn Ihr Server jedoch kompromittiert ist und das Salt kompromittiert ist, wird es möglich, eine Reihe bekannter Hashes zu generieren und ein Reverse-Lookup eines bestimmten Passworts zu versuchen. Endeffekt? Hash Ihre Benutzerpasswörter mit einem Salz.
Drittens stammen die meisten Sicherheitslücken nicht von Spoofing-Sitzungen. Sie kommen von einer schlechten Eingangsprüfung. Ein Buch wie Essential PHP Security sollte eine gute Einführung in die Art der Eingabe sein, die Sie in einem PHP-Projekt überprüfen sollten. Gelingt dies nicht, lesen Sie zumindest den Sicherheitsbereich des PHP Manuals . Achten Sie auf das SQL-Injection-Bit. Es ist cool!
Schließlich stimme ich dem anderen Poster voll und ganz zu, dass Sie SSL verwenden sollten, um die Kommunikation mit Ihrer Website zu sichern.
Um ehrlich zu sein, ich denke, Sie sind übervorsichtig, aber nicht auf eine sehr nützliche Weise.
Wenn Sie sich wirklich Sorgen um die Sitzungssicherheit machen, versuchen Sie es nicht selbst. Verwenden Sie einen PHP-Sicherheitspatch wie Suhosin . Lass es die ganze harte Arbeit für dich tun. Suhosin ist ein etablierter Patch für PHP. Es enthält Sachen, die sich mit allen Arten befassen, wie eine PHP-Sitzung gehackt werden kann. Wenn Sie es installiert haben, müssen Sie nichts extra tun, um Ihre Sitzung zu sichern. Wenn Sie es nicht installiert haben, dann können Sie definitiv nicht behaupten, dass die Sicherheit sehr paranoid ist!
Kurz gesagt, installiere Suhosin (falls du es noch nicht getan hast) und vergiss es.
Aber nur der Vollständigkeit halber werde ich ein paar Kommentare zu Ihrem eigentlichen Code machen, nur um auf einige Dinge hinzuweisen:
Ich bin nicht sicher, warum Sie denken, dass MD5-Hashing einen Unterschied macht. MD5-Hashes können in Sekunden geknackt werden, so dass sie in jeder Art von Sicherheitsfunktion verwendet werden können, ist völlig willkürlich. Es kann auch einfacher Text sein. Das heißt, ich sehe nicht wirklich, dass sie irgendetwas anderes als nur Text sein müssen - wenn ein Hacker es geschafft hat, die Sitzungsdaten zu bekommen, um die IP-Adresse lesen zu können, die er enthält, dann bist du es nicht nur darüber, ob sie die IP-Adresse kennen oder nicht.