Sicherheit des $_SESSION-Arrays

Question

Wenn sich ein Nicht-Administrator-Benutzer mit geringen Rechten erfolgreich bei meiner Webanwendung anmeldet, speichere ich die folgenden Daten in der $_SESSION Array:

$_SESSION = array(
    'user_id'     => 2343,  // whatever their user_id number is from the DB
    'allow_admin' => false, // don't give them access to admin tools
    'allow_edit'  => false, // don't let them edit stuff
    );

Gibt es irgendeine Möglichkeit, dass sie die Daten manipulieren können? $_SESSION Array, um ihnen Admin- oder Edit-Zugriff zu geben, abgesehen von der Bearbeitung der Sitzungsdateien in /tmp ? (Der obige Code ist die einzige Stelle, an der diese Elemente zu $_SESSION )

Answer 1

Der Inhalt der Sitzung ist nur auf der Serverseite sichtbar und veränderbar.

Sie könnten nur dann auf "unautorisierte" Weise geändert werden, wenn Ihre Anwendung oder Ihr Server eine Schwachstelle aufweist.

Sie sollten auch auf folgende Dinge achten Angriffe zur Sitzungsfixierung Dabei zwingt ein Angreifer einem ahnungslosen Benutzer eine bestimmte Sitzungskennung auf, der sich dann anmeldet und die Berechtigungen dieser Sitzung erhöht, so dass ein Angreifer diese Sitzung gemeinsam nutzen kann.

Ein Ansatz zur Abschwächung dieser Probleme besteht darin, dass die Sitzungsnummer neu generieren wenn Sie die Berechtigungsstufen der Sitzung ändern.

Siehe auch diese Frage:

• PHP-Session-Sicherheit

Answer 2

Wenn Sie vermeiden wollen, dass Javascript Ihre Cookies ausliest und Man-in-the-Middle-Angriffe durchführt, müssen Sie einen Server mit https verwenden und das Sitzungs-Cookie so einstellen, dass es nur über https transportiert wird.

session.cookie_secure gibt an, ob Cookies nur über sichere Verbindungen gesendet werden sollen. Die Voreinstellung ist off. Diese Einstellung wurde in PHP 4.0.4 hinzugefügt. Siehe auch session_get_cookie_params() und session_set_cookie_params().

session.cookie_httponly Markiert das Cookie als nur über das HTTP-Protokoll zugänglich. Dies bedeutet, dass das Cookie nicht über Skriptsprachen wie JavaScript zugänglich ist. Diese Einstellung kann wirksam dazu beitragen, Identitätsdiebstahl durch XSS-Angriffe zu verhindern (obwohl sie nicht von allen Browsern unterstützt wird).

Um die Admin-Rechte besser zu schützen, wenn jemand seinen Computer für ein paar Minuten unbewacht lässt, sollten Sie einen Timer für die letzte (Admin-)Anmeldung einrichten. Wenn dieser Zeitpunkt mehr als x Zeiteinheiten entfernt ist, muss sich der Benutzer erneut anmelden, um die Administratorrechte zu nutzen.

Kürzere Sitzungen sind auch sicherer als längere.

Answer 3

Server

Sitzungen werden auf dem Server gespeichert. Ein Benutzer könnte die Sitzungsdaten ändern, wenn er direkten Zugriff auf das Verzeichnis hat, in dem die Sitzungen gespeichert sind. Eine Lösung für dieses Problem besteht darin, das Verzeichnis zu sichern. Und stellen Sie sicher, dass Sie keine Lücke in Ihrem PHP-Code haben, durch die die user_id durch $_POST oder $_GET gesetzt werden kann.

Kunde

Aber auf der Client-Seite ist die Manipulation von Sitzungen möglich von Entführung jemandes session_id. Dadurch kann sich der Hijacker als dieser Benutzer ausgeben. und in seinem Namen eine Anfrage senden.

Außerdem gibt es Cross-Site Request Forgery . Dies ist der Fall, wenn ein Hacker einen Benutzer dazu verleitet, Anfragen für er . Zum Beispiel, indem Sie ihn dazu bringen, auf einen Link zu klicken. Sie könnten dies mit Token bekämpfen. Ein Token ist eine generierte Zeichenfolge, die in das Array $_SESSION und in jedes HTML-Formular als verstecktes Feld eingefügt wird. Wenn der Benutzer ein Formular abschickt, werden die Werte gegeneinander geprüft. Und jedes Mal, wenn der Benutzer eine neue Seite anfordert, ändert sich das Token. Auf diese Weise muss ein Angreifer versuchen, das Token vorherzusagen, was ziemlich schwierig ist, je nachdem, wie man das Token erstellt.

Die Links zeigen auch Beispiele für diese Angriffe.

Answer 4

Wenn Sie in Ihrem Skript keinen solchen Zugang anbieten, können die Benutzer nicht viel dagegen tun. Ihre Sitzungsdaten sollten also ziemlich sicher sein. Das Einzige, was der Benutzer tun kann, ist, den Sitzungscookie oder die in der URL übergebene Sitzungs-ID zu manipulieren, aber es ist unwahrscheinlich, dass er eine bestehende Sitzungs-ID eines anderen Benutzers findet.

Answer 5

Es sei denn, Sie haben irgendwo eine Sicherheitslücke gelassen (z. B. indem Sie Benutzern das Hinzufügen/Ändern von $_SESSION-Daten irgendwie ermöglichen).