Globales Session Management
Das Standardverhalten von Sessions kann mit Hilfe der statischen Methoden von
Zend_Session geändert werden. Das komplette Management und die
Manipulation des globalen Session Managements findet durch Verwendung von
Zend_Session statt, was auch die Konfiguration der » üblichen Optionen, welche von
ext/session unterstützt werden, durch
Zend_Session::setOptions() enthält. Zum Beispiel kann, das
fehlerhafte Versichern das ein sicherer Konfigurations OptionenWenn der erste Session Namensraum angefragt wird, startet Zend_Session automatisch die PHP Session, ausser er wurde bereits mit Zend_Session::start() gestartet. Die darunterliegende PHP Session verwendet die Standards von Zend_Session, ausser wenn Sie schon durch Zend_Session::setOptions() modifiziert wurde.
Um eine Konfigurations Option einer Session zu setzen, muß der Basisname (der Teil des
Namens nach " Example #1 Verwenden von Zend_Config um Zend_Session zu konfigurieren Um diese Komponente mit Hilfe von Zend_Config_Ini zu konfigurieren, muß zuerst die Konfigurations-Option dem INI File hinzugefügt werden:
Als nächstes die Konfigurationsdatei laden und dessen Array Representation Zend_Session::setOptions() übergeben:
Die meisten der oben gezeigten Optionen benötigen keine Erklärung die nicht in der Standard PHP Dokumentation gefunden werden kann, aber jene von speziellem Interesse sind anbei beschrieben.
Fehler: Header schon gesendetWenn die Fehler Nachricht, "Cannot modify header information - headers already sent", oder "You must call .. before any output has been sent to the browser; output started in ..." erscheint, sollte der direkte Grund (Funktion oder Methode) der mit dieser Nachricht gekoppelt ist sorgfältig begutachtet werden. Jede Aktion die das senden von HTTP Headern benötigt, wie z.B. das modifizieren von Browser Cookies, muß vor dem Senden von normaler Ausgabe (ungepufferter Ausgabe) durchgeführt werden, ausser wenn PHP's Ausgabebuffer verwendet wird.
Session IdentifiziererEinführung: Die beste Praxis in Relation für die Benutzung von Session innerhlab des ZF fordert die Verwendung eines Browser Cookies (z.B. ein normales Cookie welchem im Web Browser gespeichert wird), statt der integration von eindeutigen Session Identifizierern in URLs als Mittel für das verfolgen von individuellen Benutzern. Normalerweise verwendet diese Komponente nur Cookie für die Handhabung von Session Identifizierern. Der Wert des Cookies ist der eindeutige Identifizierer in der Session des Browsers. PHP's ext/session verwendet diesen Identifizierer um eine eindeutige eins-zu-eins Verbindung zwischen dem Besucher der Webseite und dem dauerhaften Session Daten Speicher herzustellen. Zend_Session* umhüllt diesen Speichermechanismus ($_SESSION) mit einem objektorientierten Interface. Leider, wenn ein Angreifer Zugriff auf der Wert des Cookies (die Session Id) erhält, kann er die Session des Besuchers übernehmen. Dieses Problem gilt nicht nur für PHP oder den Zend Framework. Die regenerateId() Methode erlaubt einer Anwendung die Session Id (die im Cookie des Besuchers gespeichert ist) in einen neuen, zufälligen, unvorhersagbaren Wert zu ändern. Achtung: Auch wenn nicht das gleiche gemeint ist, um diese Sektion einfacher lesbar zu machen, verwenden wir die Ausdrücke "User Agent" und "Webbrowser" synonym füreinander. Warum?: Wenn ein Angreifer einen gültigen Session Identifizierer erhält, kann ein Angreifer einen gültigen Benutzer (das Opfer) verkörpern, und anschließend Zugriff auf vertrauliche Intormationen oder andererseits die Daten des Opfers verändern welche von der Anwendung verwaltet werden. Das Ändern des Session Id's hilft sich gegen die Übernahme der Session zu Schützen. Wenn die Session Id geändert wird, und ein Angreifer den neuen Wert nicht weiß, kann der Angreifer die neue Session Id nicht für Ihren Zweck, dem Versuch der Übernahme der Session des Opfers, verwenden. Selbst wenn der Angreifer zugriff auf die alte Session Id erhält, verschiebt regenerateId() die Daten der Session vom alten Session Id "Handle" zum neuen, weswegen keine Daten über die alte Session Id abrufbar sind. Wann sollte regenerateId() verwendet werden: Das Hinzufügen von Zend_Session::regenerateId() in die Bootstrap Datei des Zend Frameworks bietet einen der sichersten und am besten geschützten Wege um die Session Id's in den Cookies der User Agenten zu erneuern. Wenn es keine bedingte Logik gibt, um herauszufinden wann die Session Id erneuert werden soll, dann gibt es keinen Mangel in dieser Logik. Auch wenn der Erneuern bei jeder Anfrage einen möglichen Weg der Attacke verhindert, will nicht jedermann die damit hervorgerufenen kleinen Einbußen in der Geschwindigkeit und der Bandbreite hinnhmen. Deswegen versuchen Anwendungen normalerweise Situationen von größerem Risiko zu erahnen, und nur in diesen Situationen die Session Id's zu erneuern. Immer wenn die Rechte einer Session vom Besucher der Webseite "ausgeweitet" werden (z.B. ein Besucher muß noch einmal seine Identität authentifizieren bevor sein "Profil" bearbeitet werden darf), oder wann auch immer ein sicherheits-"sensitiver" Session Parameter geändert wird, sollte daran gedacht werden regenerateId() zu verwenden um eine neue Session Id zu erstellen. Wenn die rememberMe() Funktion aufgerufen wird, sollte regenerateId() nicht verwendet werden, ausser der erstere ruft den letzteren auf. Wenn sich ein Benutzer erfolgreich auf die Webseite eingeloggt hat, sollte rememberMe() statt regenerateId() verwendet werden. Session-Entführung und Fixierung
Das Vermeiden von
» Seiten übergreifenden
Script (XSS) Gefährdungen hilft bei der Vorbeugung von Session Entführungen.
Laut » Secunia's Statistik kommen XSS
Probleme häufig vor, unabhängig von der Sprache dir für die Erstellung der Web
Anwendung benutzt wurde. Vor der Annahme nie XSS Probleme mit einer Anwendung zu
haben, sollten diese mit der folgenden besten Praxis berücksichtigt werden um, wenn
sie auftreten, den geringsten Schaden zu haben. Mit XSS benötigt ein Angreifer
keinen direkten Zugriff auf den Netzwerk Verkehr des Opfers. Wenn das Opfer bereits
ein Session Cookie hat, kann Javascript XSS einem Angreifer erlauben das Cookie zu
lesen und die Session zu stehlen. Für Opfer ohne Session Cookies, kann ein
Angreifer, wenn er XSS verwendet um Javascript einzuschleusen, ein Session Id Cookie
mit einem bekannten Wert, auf dem Browser des Opfers erstellen, und dann ein
identisches Cookie auf dem System des Angreifers setzen, um die Session des Opfers
zu entführen. Wenn das Opfer die Webseite des Angreifers besucht, kann der Angreifer
auch die meisten anderen infizierbaren Characteristiken vom User Agent des Opfers
emulieren. Wenn eine Webseite eine XSS Gefährdung aufweist, könnte der Angreifer ein
AJAX Javascript einfügen das versteckt die Webseite des
Angreifers "besucht", damit der Angreifer die Characteristika vom Browser des Opfers
weiß und auf die beeinträchtigte Session auf der Webseite des Opfers aufmerksam
gemacht wird. Trotzdem kann ein Angreifer nicht willkürlich die serverseitigen
Status der PHP Session ändern, wenn der Entwickler den Wert für
die
Nur durch das Aufrufen von Zend_Session::regenerateId(),
wenn die Session des Benutzers das erste Mal verwendet wird, verhindert keine
Session Fixierungs Attacken, ausser es kann die Session, die von einem Angreifer
erstellt wurde um ein Opfer zu Emulieren, unterschieden werden. Das könnte zuerst
wiedersprüchlich klingen zu dem vorherigen Statement, solange angenommen wird das
ein Angreifer zuerst eine reale Session auf der Webseite initiiert. Die Session wird
"zuerst vom Angreifer benutzt", welche dann das Ergebnis der Initialisierung weiß
( regenerateId()). Der Angreifer verwendet dann diese neue
Session Id in Kombination mit der XSS Gefährdung, oder injiziert die Session Id über
einen Link auf der Webseite des Angreifers (funktioniert wenn
Wenn zwischen einem Angreifer und einem Opfer welche die selbe Session Id verwenden, unterschieden werden kann, kann mit der Session Enführung direkt gehandelt werden. Trotzdem beinhalten solche Formen von Unterscheidungen normalerweise eine Verringerung der Handhabung weil diese Methoden der Unterscheidung oft ungenau sind. Wenn, zum Beispiel, eine Anfrage von einer IP in einem anderen Land empfangen wird als von der IP in welchem die Session erstellt wurde, gehört die neue Anfrage möglicherweise zu einem Angreifer. Unter der folgenden Annahme, gibt es möglicherweise keinen Weg, für eine Webseiten Anwendung, zwischen einem Opfer und einem Angreifer zu unterscheiden:
Example #2 Session Fixierung
>rememberMe(integer $seconds)
Normalerweise enden Sessions wenn der User Agent terminiert, wie wenn der End-Benutzer
seinen WebBrowser schließt. Trotzdem kann die Anwendung die Möglichkeit bieten, eine
Benutzer Session über die Lebensdauer des Client Programms hinweg zu verlängern durch
die Verwendung von persistenten Cookies.
Zend_Session::rememberMe() kann vor dem Start der Session
verwendet werden um die Zeitdauer zu kontrollieren bevor ein persistentes Session Cookie
abläuft. Wenn keine Anzahl an Sekunden definiert wird, verwendet das Session Cookie
standardmäßig eine Lebenszeit von forgetMe()Diese Funktion ist das Gegenteil von rememberMe() durch Schreiben eines Session Cookies das eine Lebenszeit hat die endet wenn der Benutzer terminiert. sessionExists()Diese Methode kann verwendet werden um Herauszufinden ob eine Session für den aktuellen User Agent/Anfrage bereits existiert. Das kann vor dem Starten einer Session verwendet werden, und ist unabhängig von allen anderen Zend_Session und Zend_Session_Namespace Methoden. destroy(bool $remove_cookie = true, bool $readonly = true)Zend_Session::destroy() entfernt alle deuerhaften Daten welche mit der aktuellen Session verbunden sind. Aber es werden keine Variablen in PHP verändert, so das die benannte Session (Instanzen von Zend_Session_Namespace) lesbar bleibt. Es ein "Logout" fertigzustellen, muß der optionale Parameter auf TRUE (standard) gesetzt werden um auch das Session Id Cookie des User Agents zu löschen. Der optionale $readonly Parameter entfernt die Möglichkeit neue Zend_Session_Namespace Instanzen zu erstellen und für Zend_Session in den Session Daten Speicher zu schreiben. Wenn die Fehlermeldung "Cannot modify header information - headers already sent" erscheint, sollte entweder die Verwendung von TRUE als Wert für das erste Argument (die Entfernung des Session Cookies anfragen) vermieden werden, oder in diesem Abschnitt nachgesehen werden. Deswegen muß entweder Zend_Session::destroy(true) aufgerufen werden bevor PHP HTTP Header gesendet hat, oder die Pufferung der Ausgabe muß aktiviert sein. Auch die komplette Ausgabe die gesendet werden soll, darf die gesetzte Puffergröße nicht überschreiten, um das Senden der Ausgabe vor dem Aufruf von destroy() zu Verhindern.
stop()Diese Methode macht nicht mehr als ein Flag in Zend_Session zu wechseln um weiteres Schreiben in den Session Daten Speicher zu verhindern. Wir erwarten spezielles Feedback für dieses Feature. Potentielle Nicht-/Verwendung könnte temporär bei Verwendung von Zend_Session_Namespace Instanzen oder Zend_Session Methoden verhindern das auf den Session Daten Speicher geschrieben wird, während deren Ausführung zum Code der View transferiert wird. Versuche Aktionen auszuführen welche das Schreiben über diese Instanzen oder Methoden inkludieren werden eine Ausnahme werfen. writeClose($readonly = true)Beendet die Session, schließt das schreiben und entfernt $_SESSION vom Backend Speicher Mechanismus. Das vervollständigt die interne Transformation der Daten auf diese Anfrage. Der optionale boolsche $readonly Parameter kann den Schreibzugriff entfernen durch das werfen einer Ausnahme bei jedem Versuch in eine Session durch Zend_Session oder Zend_Session_Namespace zu schreiben.
expireSessionCookie()Diese Methode sendet ein abgelaufenes Session Id Cookie, was den Client dazu bringt den Session Cookie zu löschen. Manchmal wird diese Technik dazu verwendet einen Logout auf der Seite des Client auszuführen. setSaveHandler(Zend_Session_SaveHandler_Interface $interface)Die meisten Entwickler werden den Standardmäßigen Speicher Handle ausreichend finden. Diese Methode bietet einen objekt-orientierten Wrapper für » session_set_save_handler(). namespaceIsset($namespace)Diese Methode kann dazu verwendet werden um herauszufinden ob ein Session Namensraum existiert, oder ob ein bestimmter Index in einem bestimmten Namensraum existiert.
namespaceUnset($namespace)Zend_Session::namespaceUnset($namespace) kann verwendet werden um effektiv den kompletten Namensraum und dessen Inhalt zu entfernen. Wie mit allen Arrays in PHP, wenn eine Variable die ein Array enthält entfernt wird, und das Array andere Objekte enthält, werden diese verfügbar bleiben, wenn diese durch Referenz in anderen Array/Objekten gespeichert sind, die durch anderen Variablen erreichbar bleiben. namespaceUnset() führt kein "tiefes" entfernen/löschen von Inhalten eines Eintrages im Namensraum durch. Für eine detailiertere Erklärung sollte im PHP Handbuch unter » Referenzen erklärt nachgesehen werden.
namespaceGet($namespace)DEPRECATED: getIterator() in Zend_Session_Namespace sollte verwendet werden. Diese Methode gibt ein Array mit dem Inhalt von $namespace zurück. Wenn es logische Gründe gibt diese Methode öffentlich aufrufbar zu lassen bitte ein Feedback auf die » fw-auth@lists.zend.com Mailingliste geben. Aktuell ist jede Anteilnahme an irgendeinem relevanten Thema sehr willkommen :)
getIterator()getIterator() kann verwendet werden, um ein Array zu erhalten, das die Namen aller Namensräume enthält.
|