Wenn 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 ...", 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.

Einfü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' 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.

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 save_path Option richtig eingestellt hat.

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 use_only_cookies = off).

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:

Der Beispiel-Code anbei, macht es für Angreifer viel schwerer die aktuelle Session Id des Opfers zu wissen solange der Angreifer nicht bereits die ersten Zwei Schritte von oben ausgeführt hat.

<?php
require_once 'Zend/Session.php';
$defaultNamespace = new Zend_Session_Namespace();

if (!isset($defaultNamespace->initialized))
{
    Zend_Session::regenerateId();
    $defaultNamespace->initialized = true;
}
?>