Wie sicher sind PHP-Sitzungsvariablen?

Question

Ich habe ein Anmeldeskript, das einen Benutzernamen und ein Kennwort mit Daten in einer Tabelle "user" vergleicht. Außerdem habe ich eine Tabelle "Rollen", in der die Zugriffsebene eines bestimmten Benutzers angegeben ist. Angenommen, ich verwende sichere Anmeldeskripte, gibt es dann irgendwelche Sicherheitslücken, wenn ich nach erfolgreicher Anmeldung einfach eine zusätzliche Abfrage an die Tabelle "roles" durchführe, um die Berechtigungsstufe des Benutzers zu ermitteln und diese in einer Sitzungsvariablen zu speichern? Die Idee wäre dann, dass ich auf jeder Seite mit gemischten Berechtigungen einfach die Sitzungsvariable abfragen könnte, um die Berechtigungsstufe des eingeloggten Benutzers zu ermitteln.

Gracias.

Answer 1

Sitzungen sind wesentlich sicherer als z. B. Cookies. Aber es ist immer noch möglich, eine Sitzung zu stehlen, und der Hacker hat dann vollen Zugriff auf alles, was sich in dieser Sitzung befindet. Einige Möglichkeiten, dies zu vermeiden, sind die IP-Prüfung (die zwar recht gut funktioniert, aber nur eine sehr geringe Sicherheit bietet und daher allein nicht zuverlässig ist) und die Verwendung eines Nonce. Bei einem Nonce gibt es in der Regel einen "Token" pro Seite, so dass jede Seite prüft, ob das Nonce der letzten Seite mit dem gespeicherten übereinstimmt.

Bei beiden Sicherheitsüberprüfungen kommt es zu einem Verlust an Benutzerfreundlichkeit. Wenn Sie eine IP-Prüfung durchführen und der Benutzer sich hinter einer Intranet-Firewall (oder einer anderen Situation, die dies verursacht) befindet, die keine feste IP für diesen Benutzer speichert, muss er sich jedes Mal neu authentifizieren, wenn er seine IP verliert. Mit einer Nonce erhält man die immer wieder lustige Situation "Wenn man zurückklickt, bricht diese Seite ab".

Aber mit einem Cookie kann ein Hacker die Sitzung einfach stehlen, indem er recht einfache XSS-Techniken anwendet. Wenn Sie die Sitzungs-ID des Benutzers in einem Cookie speichern, ist er auch dafür anfällig. Auch wenn die Sitzung also nur von jemandem durchdrungen werden kann, der einen Hack auf Serverebene durchführen kann (wofür wesentlich ausgefeiltere Methoden und in der Regel ein gewisses Maß an Privilegien erforderlich sind, wenn Ihr Server sicher ist), benötigen Sie dennoch bei jeder Skriptanforderung eine zusätzliche Verifizierung. Sie sollten Cookies und AJAX nicht zusammen verwenden, da dies es ein wenig einfacher macht, sich völlig auszutoben, wenn das Cookie gestohlen wird, da Ihre AJAX-Anfragen möglicherweise nicht bei jeder Anfrage einer Sicherheitsüberprüfung unterzogen werden. Wenn die Seite beispielsweise eine Nonce verwendet, aber nie neu geladen wird, prüft das Skript möglicherweise nur auf diese Übereinstimmung. Und wenn das Cookie die Authentifizierungsmethode enthält, kann ich nun mit dem gestohlenen Cookie und dem AJAX-Loch mein Unwesen treiben.

Answer 2

Nur Skripte, die auf Ihrem Server ausgeführt werden, haben Zugriff auf das _SESSION-Array. Wenn Sie den Geltungsbereich des Sitzungscookies festlegen, können Sie ihn sogar auf ein bestimmtes Verzeichnis beschränken. Die einzige Möglichkeit, wie jemand anderes als Sie an die Sitzungsdaten gelangen könnte, ist das Einfügen von PHP-Code in eine Ihrer Seiten.

Was das von Ihnen verwendete System betrifft, so ist es akzeptabel und eine gute Möglichkeit, Datenbankaufrufe zu sparen, aber bedenken Sie, dass der Benutzer sich ab- und wieder anmelden muss, damit alle Berechtigungsänderungen wirksam werden. Wenn Sie also ein Konto sperren möchten und der Benutzer bereits angemeldet ist, können Sie das nicht.

Answer 3

Es ist zu beachten, dass im Apache die PHP-Superglobale $_SESSION über virtuelle Hosts hinweg zugänglich ist. Betrachten Sie dieses Szenario:

• Ihr Server hostet zwei Domänen, example.com und instance.org. PHP-Sitzungen werden in Cookies gespeichert, die auf die Domäne beschränkt sind.
• Ein Benutzer meldet sich bei example.com an und erhält eine Sitzungs-ID. Beispiel.com setzt einige Sitzungsvariablen (die auf dem Server und nicht im Cookie gespeichert werden).
• Eine dritte Partei fängt das Cookie während der Übertragung ab und leitet es an instance.org weiter. Instance.org hat nun Zugriff auf die Sitzungsvariablen von example.com.

Das ist nicht so schlimm, wenn Sie alle virtuellen Hosts auf Ihrem Server kontrollieren, aber wenn Sie auf einem gemeinsam genutzten Rechner sind, ist es problematisch.

Answer 4

Wenn Sie sich auf einen in einer Sitzungsvariablen gespeicherten Wert verlassen, um die Rollen zu bestimmen, verlieren Sie die Möglichkeit, den Wert in der DB zu ändern und ihn in der aktuellen Sitzung des Benutzers zu berücksichtigen. Wenn man sich das Zend Framework anschaut, gibt es eine klare Unterscheidung zwischen Authentifizierung und Autorisierung, und stark formulierte Warnungen im Handbuch, nur die minimale Menge an Daten in der Session zu speichern (z.B. "Yup, he's user #37 & he logged in").

Was die "Sicherheit" betrifft, so gibt es keinen Grund zur Sorge, es sei denn, Sie sind auf einem gemeinsam genutzten Host. Auf einem richtig konfigurierten Shared Host sollten sie auch relativ sicher sein.