it-swarm.com.de

WordPress und PHP Sitzungen - Sicherheit und Leistung

Ich schreibe ein WordPress-Plugin für eine Drittanbieter-API.

Für diese API muss eine Sitzungs-ID übergeben werden, damit die API (die im Grunde genommen als Einkaufswagen eines Drittanbieters fungiert) weiß, welcher Artikel an welcher Stelle hinzugefügt werden soll. Stellen Sie sich dies wiederum wie einen Einkaufswagen vor.

Ich möchte diese Sitzungskennung in den Sitzungen meiner WordPress-Benutzer speichern. Die Idee wäre, eine Verbindung zu dieser API herzustellen, die Sitzungs-ID anzufordern und sie dann in der WordPress/PHP-Sitzung zu speichern, damit ich sie wiederverwenden kann, wenn sie auf der Website navigieren und weitere Artikel in den Warenkorb eines Drittanbieters legen. Ich erkenne, dass dies nicht ideal ist (warum nicht WooCommerce, um dies direkt zu tun?), Aber wir benötigen einige zusätzliche Funktionen und Daten, die nur dieser Drittanbieter bereitstellen kann.

Wie auch immer, als ich versuchte, dies zu tun, fand ich dies von unserem Host:https://wpengine.com/support/cookies-and-php-sessions/

Was ich gestehe, finde ich furchtbar verwirrend.

Demnach sind PHP Sessions und Funktionen wie session_start() und session_id() nicht ratsam und funktionieren auf diesem Host nicht - ... unser System ignoriert speziell Header Definieren eines PHPSESSID-Cookies.

Aber wie in den Dokumenten darauf hingewiesen wird, -WENN PHP SESSIONS EINE ART VON COOKIE SIND, WAS IST DAS PROBLEM?

In meinen Augen beantworten diese Dokumente diese Frage nicht.

Es sagt:

Der größte Konflikt bei der Verwendung von PHP Sitzungen hat mit den eindeutigen Sitzungskennungen zu tun. Da die ID-Zeichenfolge jedes Benutzers eindeutig ist, wird dieser Cache bei jedem neuen Benutzer, der Ihre Website besucht, gelöscht. Diese Art von System kann nicht mit vielen gleichzeitigen Site-Benutzern skaliert werden! Aus diesem Grund ignoriert unser System speziell Header, die ein PHPSESSID-Cookie definieren.

Meine Frage hier ist, trifft dies nicht auf die Sitzungen zu, die sie befürworten, und die über lediglich ein anderes Cookie durchgeführt werden, was dann zu einer Datenbankverbindung führt?

Sie sagen hier:

In Wirklichkeit gibt es eine bessere Möglichkeit, Sitzungsdaten von Benutzern zu speichern! Die korrekte Methode besteht darin, die Datenbank zum Speichern von Sitzungsdaten zu verwenden. WooCommerce und andere E-Commerce-Lösungen haben diese Methode bereits gegenüber herkömmlichen PHP Sessions und verwenden Sie auch ihre eigenen Cookie-Namenskonventionen verwendet.

Diese Dokumente gehen weiter:

Neben den Auswirkungen auf Leistung und Skalierung treten in PHP Sitzungen auch andere Probleme auf. Standardmäßig speichern PHP Sitzungen Daten im Dateisystem als eigene eindeutige Datei. Das Schreiben von Daten in eine Datei ist ein E/A-Prozess. Es ist bekannt, dass diese Prozesse eine Sicherung durchführen und eine hohe Serverauslastung verursachen, wenn auf Ihrer Site zu viele Benutzer gleichzeitig angemeldet sind. Ganz zu schweigen davon, dass diese Art der Sitzungsspeicherung einfach nicht funktioniert, wenn sich Ihre Site auf einer Clusterlösung befindet, die sich über mehrere Webserver erstreckt.

Warum ist dies schlechter/besser als das Speichern der Sitzungen in einer Datenbank? Ist das nicht auch I/O?

Ich versuche zu verstehen, warum die Standardsitzung PHP als schlecht und die WooCommerce-Sitzung als gut eingestuft wird. Ich habe mir den WooCommerce-Quellcode für Sitzungen angesehen, aber ich bin in diesem Bereich nicht erfahren genug, um zu verstehen, warum das, was sie tun, Schwachstellen vermeidet, wie in den Host-Dokumenten erwähnt.

Speziell:

Es gibt mehrere Sicherheitslücken, die sich um PHP Sitzungen drehen. Sicherheitsanfälligkeiten umfassen offen gelegte Sitzungsdaten, Sitzungsfixierung und Sitzungsentführung.

Wie mildert WooCommerce dies, wenn PHP Sitzungen dies nicht tun? Was ist für meinen Anwendungsfall ratsam?

Natürlich möchte ich keine unsicheren Sitzungen, aber die Entwicklung einer Sitzungsmanager-/Cookie-/Datenbankverbindung, wie es Woo anscheinend getan hat, würde einige Zeit in Anspruch nehmen. Deshalb versuche ich zu verstehen, warum/ob dies notwendig ist, um zu replizieren, bevor ich die Zeit in das Vermeiden von PHP Sitzungen investiere.

6
TooHotToHandle

Dies hat sehr wenig mit WordPress zu tun, aber wenn diese Antwort dazu beiträgt, dass keine Sitzung mehr verwendet wird, lohnt es sich möglicherweise ...

Sitzungen werden auf der Festplatte des Servers gespeichert. Dies ist in einem Szenario mit gemeinsamem Hosting problematisch, da das Sitzungsverzeichnis höchstwahrscheinlich von allen auf dem Server ausgeführten Prozessen und nicht nur von Ihrer Site gelesen und beschrieben werden kann. Alle gemeinsam genutzten Ressourcen auf einem gemeinsam genutzten Hosting-Server, die keinen benutzerbasierten Schutz auf Betriebssystemebene bieten (z. B. Verzeichnisberechtigungen), sind zumindest verdächtig und sollten nicht für sichere oder private Zwecke verwendet werden.

lässt sich wiederholen Sitzungen werden auf der Festplatte des Servers gespeichert . Was passiert, wenn Sie in einer Umgebung mit mehreren Servern arbeiten? Wie können Sie Ihre Sitzungsinformationen finden? Die einzige Möglichkeit, dies zu erreichen, besteht darin, Benutzer an bestimmte Server zu binden, was nicht optimal ist.

Und wieder Sitzungen werden auf der Festplatte des Servers gespeichert . Wenn Sie Sitzungen als integralen Bestandteil Ihrer HTML-Generierung verwenden, bedeutet dies, dass Sie Ihr HTML nicht zwischenspeichern können.

WPEngine ist ein gemeinsam genutztes Hosting in einer Umgebung mit mehreren Servern, das standardmäßig Caching ausführt.

Wie in Ihrem Zitat erwähnt, verwenden WC keine PHP-Sitzungen und erfinden ihren eigenen Mechanismus, indem sie Sitzungsinformationen in der Datenbank speichern. Dies ist auch eine problematische Lösung, da starke Zugriffe die Website möglicherweise zum Erliegen bringen, wenn Sie dies nicht mit äußerster Sorgfalt tun (in diesem Fall wird die Sitzung vermutlich erst gestartet, wenn ein Benutzer mit dem Kauf eines Produkts beginnt). Warum sie das so machen und sich nicht auf Cookies verlassen, werden Sie fragen müssen. Ich gehe davon aus, dass die Verfolgung unvollständiger Transaktionen ein Teil davon ist. Ein anderer Teil ist, dass Cookie-Informationen auf http-Sites grundsätzlich öffentlich sind und wenn Sie dies vermeiden möchten Informationsleck müssen Sie auf dem Server speichern.

Was ist in Ihrem Fall zu empfehlen? Ohne weitere Details ist dies schwer zu sagen, aber wahrscheinlich sollten Sie daran arbeiten, alles zu vermeiden, was sich wie eine Sitzung anfühlt. HTTP wurde nicht für Sitzungen entwickelt, und es ist am besten, diese Tatsache des Lebens nicht zu bekämpfen.

2
Mark Kaplun