1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678
|
<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: no -->
<sect1 id="zend.session.global_session_management">
<title>Globales Session Management</title>
<para>
Das Standardverhalten von Sessions kann mit Hilfe der statischen Methoden von
<classname>Zend_Session</classname> geändert werden. Das komplette Management und die
Manipulation des globalen Session Managements findet durch Verwendung von
<classname>Zend_Session</classname> statt, was auch die Konfiguration der <ulink
url="http://www.php.net/session#session.configuration">üblichen Optionen, welche von
ext/session unterstützt werden</ulink>, durch
<methodname>Zend_Session::setOptions()</methodname> enthält. Zum Beispiel kann, das
fehlerhafte Versichern das ein sicherer <code>save_path</code> oder ein eindeutiger
Cookiename von ext/session durch <methodname>Zend_Session::setOptions()</methodname>
verwendet wird, zu einem Sicherheitsproblem werden.
</para>
<sect2 id="zend.session.global_session_management.configuration_options">
<title>Konfigurations Optionen</title>
<para>
Wenn der erste Session Namensraum angefragt wird, startet
<classname>Zend_Session</classname> automatisch die <acronym>PHP</acronym> Session,
ausser er wurde bereits mit <link
linkend="zend.session.advanced_usage.starting_a_session"><methodname>Zend_Session::start()</methodname></link>
gestartet. Die darunterliegende <acronym>PHP</acronym> Session verwendet die Standards
von <classname>Zend_Session</classname>, ausser wenn Sie schon durch
<methodname>Zend_Session::setOptions()</methodname> modifiziert wurde.
</para>
<para>
Um eine Konfigurations Option einer Session zu setzen, muß der Basisname (der Teil des
Namens nach "<code>session.</code>") als Schlüssel eines Array inkludiert und an
<methodname>Zend_Session::setOptions()</methodname> übergeben werden. Der
korrespondierende Wert im Array wird verwendet um den Wert der Option dieser Session zu
setzen. Wenn keine Option durch den Entwickler gesetzt wird, wird
<classname>Zend_Session</classname> zuerst die benötigten Optionen anwenden und
anschließend die standard php.ini Einstellungen. Feedback der Community über die beste
Handhabung für diese Optionen sollte gesendet werden an <ulink
url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink>.
</para>
<example id="zend.session.global_session_management.setoptions.example">
<title>Verwenden von Zend_Config um Zend_Session zu konfigurieren</title>
<para>
Um diese Komponente mit Hilfe von <link
linkend="zend.config.adapters.ini"><classname>Zend_Config_Ini</classname></link>
zu konfigurieren, muß zuerst die Konfigurations-Option dem <acronym>INI</acronym>
File hinzugefügt werden:
</para>
<programlisting language="ini"><![CDATA[
; Accept defaults for production
[production]
; bug_compat_42
; bug_compat_warn
; cache_expire
; cache_limiter
; cookie_domain
; cookie_lifetime
; cookie_path
; cookie_secure
; entropy_file
; entropy_length
; gc_divisor
; gc_maxlifetime
; gc_probability
; hash_bits_per_character
; hash_function
; name sollte für jede PHP Anwendung eindeutig sein und den
; selben Domain Namen verwenden
name = UNIQUE_NAME
; referer_check
; save_handler
; save_path
; serialize_handler
; use_cookies
; use_only_cookies
; use_trans_sid
; remember_me_seconds = <integer seconds>
; strict = on|off
; Entwicklung beinhaltet Konfiguration der Produktion,
; überschreibt aber diverse Werte
[development : production]
; Nicht vergessen, dieses Verzeichnis zu erstellen und es
; rwx machen (lesbar und änderbar) durch PHP.
save_path = /home/myaccount/zend_sessions/myapp
use_only_cookies = on
; Beim Analysieren von Session ID Cookies, frage nach einer TTL von 10 Tagen
remember_me_seconds = 864000
]]></programlisting>
<para>
Als nächstes die Konfigurationsdatei laden und dessen Array Representation
<methodname>Zend_Session::setOptions()</methodname> übergeben:
</para>
<programlisting language="php"><![CDATA[
$config = new Zend_Config_Ini('myapp.ini', 'development');
require_once 'Zend/Session.php';
Zend_Session::setOptions($config->toArray());
]]></programlisting>
</example>
<para>
Die meisten der oben gezeigten Optionen benötigen keine Erklärung die nicht in der
Standard <acronym>PHP</acronym> Dokumentation gefunden werden kann, aber jene von
speziellem Interesse sind anbei beschrieben.
<itemizedlist mark="opencircle">
<listitem>
<para>
boolean <code>strict</code> - verhindert das automatische Starten von
<classname>Zend_Session</classname> wenn <code>new
Zend_Session_Namespace()</code> verwendet wird.
</para>
</listitem>
<listitem>
<para>
integer <code>remember_me_seconds</code> - Wie lange soll das Session Id
Cookie bestehen, nachdem der Benutzer Agent beendet wurde (z.B. Browser
Anwendung geschlossen)
</para>
</listitem>
<listitem>
<para>
string <code>save_path</code> - Der richtige Wert ist abhängig vom System,
und sollte vom Entwickler auf einen <emphasis>absoluten Pfad</emphasis> zu
einem Verzeichnis bereitgestellt werden, welches durch den
<acronym>PHP</acronym> Prozess lesbar und beschreibbar ist. Wenn kein
schreibbarer Pfad gegeben ist, wird <classname>Zend_Session</classname> eine
Ausnahme werden sobald Sie gestartet wird (z.B. wenn
<methodname>start()</methodname> aufgerufen wird).
</para>
<note>
<title>Sicherheits Risiko</title>
<para>
Wenn der Pfad von einer anderen Anwendung aus lesbar ist, kann die
Entführung der Session möglich sein. Wenn der Pfad von einer anderen
Anwendung aus beschreibbar ist, kann die <ulink
url="http://en.wikipedia.org/wiki/Session_poisoning">Session
vergiftet</ulink> werden. Wenn der Pfad mit anderen Benutzern oder
anderen <acronym>PHP</acronym> Anwendungen geteilt wird, können
verschiedenste Sicherheitsprobleme auftreten. Das inkludiert Diebstahl
von Inhalten der Session, Entführung von Sessions und Kollisionen der
Müllsammlung (z.B., eine andere Anwendung eines Benutzers können
<acronym>PHP</acronym> veranlassen die eigenen Session Dateien zu
löschen).
</para>
<para>
Zum Beispiel kann ein Angreifer die Webseite des Opfers besuchen um ein
Session Cookie zu erhalten. Dann, den Cookie Pfad auf die eigene Domain
auf dem gleichen Server ändern, bevor er die eigene Webseite besucht um
<methodname>var_dump($_SESSION)</methodname> auszuführen. Bewaffnet mit
detailiertem Wissen über die Verwendung von Daten in den Sessions des
Opfers, kann der Angreifer den Sessionstatus verändern (Vergiften der
Session), den Cookie Pfad auf die Webseite des Opfers zurück ändern, und
anschließend eine Anfrage von der Webseite des Opfers, mithilfe der
vergifteten Session, durchführen. Selbst wenn zwei Anwendungen auf dem
gleichen Server keinen Lese-/Schreibzugriff auf den jeweils anderen
<code>save_path</code> der Anwendung haben, wenn der
<code>save_path</code> erahnbar ist und der Angreifer die Kontrolle über
eine der zwei Webseiten hat, kann der Angreifer den
<code>save_path</code> seiner Webseiten ändern um dem anderen save_path
zu verwenden und somit die Vergiftung der Session durchführen, in den
meisten üblichen <acronym>PHP</acronym> Konfigurationen. Deshalb sollte
der Wert für <code>save_path</code> nicht öffentlich bekanntgegeben
werden, und er sollte geändert werden um dem Pfad eindeutig für jede
Anwendung zu sichern.
</para>
</note>
</listitem>
<listitem>
<para>
string <code>name</code> - Der richtige Wert ist abhängig vom System and
sollte vom Entwickler, durch Verwenden eines bestimmten Wertes,
bereitgestellt werden, welcher für jede Zend Framework Anwendung
<emphasis>eindeutig</emphasis> ist.
</para>
<note>
<title>Sicherheits Risiko</title>
<para>
Wenn die <code>php.ini</code> Einstellung für <code>session.name</code>
die selbe ist (z.B., die standardmäßige "PHPSESSID"), und es zwei oder
mehr <acronym>PHP</acronym> Anwendungen gibt die über den selben Domain
Namen erreichbar sind, dann werden Sie miteinander für alle Besucher die
beide Webseiten besuchen, die selben Session Daten teilen. Zusätzlich,
könnte das auch zu einer Verfälschung von Session Daten führen.
</para>
</note>
</listitem>
<listitem>
<para>
boolean <code>use_only_cookies</code> - Um zusätzliche Sicherheitsrisiken
zu vermeiden, sollte der Standardwert dieser Option nicht verändert werden.
<note>
<title>Sicherheits Risiko</title>
<para>
Wenn diese Einstellung nicht aktiviert wird, kann ein Angreifer
einfach die Session Id des Opfers ändern indem ein Link auf der
Webseite des Angreifers verwendet wird, wie z.B.
<code>http://www.example.com/index.php?PHPSESSID=fixed_session_id</code>.
Die Änderung funtioniert, wenn das Opfer nicht schon ein Session Id
Cookie für example.com besitzt. Sobald ein Opfer eine bekannte
Session Id benutzt, kann der Angreifer versuchen die Session zu
übernehmen indem er sich verstellt und vorgibt das Opfer zu sein,
und den UserAgent des Opfers emuliert.
</para>
</note>
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2 id="zend.session.global_session_management.headers_sent">
<title>Fehler: Header schon gesendet</title>
<para>
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 ..." erscheint, sollte der direkte Grund (Funktion oder Methode) der mit dieser
Nachricht gekoppelt ist sorgfältig begutachtet werden. Jede Aktion die das senden von
<acronym>HTTP</acronym> 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 <acronym>PHP</acronym>'s Ausgabebuffer verwendet wird.
</para>
<itemizedlist mark='opencircle'>
<listitem>
<para>
<ulink url="http://php.net/outcontrol">Puffern der Ausgabe</ulink> ist oft
notwendig um dieses Problem zu verhindern, und hilft bei der Steigerung der
Geschwindigkeit. Zum Beispiel aktiviert "<code>output_buffering = 65535</code>"
in der <code>php.ini</code> das Puffern der Ausgabe mit einem 64k Puffer. Selbst
wenn das Puffern der Ausgabe eine gute Taktik ist um auf Produktionsservern die
Geschwindigkeit zu Erhöhen, ist das Vertrauen auf das Puffern, um das Problem
"headers already sent" zu beheben, nicht ausreichend. Die Anwendung darf die
Buffergröße nicht überschreiten, andernfalls wird das Problem von Zeit zu Zeit
wieder auftreten, wann auch immer eine Ausgabe gesendet wird (vor den
<acronym>HTTP</acronym> Headern) welche die Puffergröße überschreitet.
</para>
</listitem>
<listitem>
<para>
Wenn eine Methode von <classname>Zend_Session</classname> als Verursacher der
Fehlermeldung ist, sollte die Methode sorgfältig begutachtet werden und es ist
sicher zu stellen das Sie auch wirklich in der Anwendung benötigt wird. Zum
Beispiel sendet auch die standardmäßige Verwendung von
<methodname>destroy()</methodname> einen <acronym>HTTP</acronym> Header um das
Session Cookie auf der Seite des Clients ablaufen zu lassen. Wenn das nicht
benötigt wird sollte <methodname>destroy(false)</methodname> verwendet werden,
da die Anweisungen für das Ändern von Cookies im <acronym>HTTP</acronym> Header
gesendet.
</para>
</listitem>
<listitem>
<para>
Anternativ kann versucht werden die Logik der Anwendung anders anzuordnen, so
das Aktionen welche Header manipulieren vor dem Senden von jeglicher Ausgabe
ausgeführt werden.
</para>
</listitem>
<listitem>
<para>
Jedes schließende "<code>?></code>" Tag sollte entfernt werden, wenn es am
Ende einer <acronym>PHP</acronym> Source Datei steht. Sie werden nicht benötigt
und neue Zeilen und andere beinahe unsichtbare Leerzeichen welche dem
schließenden Tag folgen können eine Ausgabe an den Client verursachen.
</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="zend.session.global_session_management.session_identifiers">
<title>Session Identifizierer</title>
<para>
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 <acronym>URL</acronym>s 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. <acronym>PHP</acronym>'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. <classname>Zend_Session</classname>*
umhüllt diesen Speichermechanismus (<varname>$_SESSION</varname>) 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 <acronym>PHP</acronym> oder den Zend Framework. Die
<methodname>regenerateId()</methodname> 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.
</para>
<para>
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
<methodname>regenerateId()</methodname> die Daten der Session vom alten Session Id
"Handle" zum neuen, weswegen keine Daten über die alte Session Id abrufbar sind.
</para>
<para>
Wann sollte regenerateId() verwendet werden: Das Hinzufügen von
<methodname>Zend_Session::regenerateId()</methodname> 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
<methodname>regenerateId()</methodname> zu verwenden um eine neue Session Id zu
erstellen. Wenn die <methodname>rememberMe()</methodname> Funktion aufgerufen wird,
sollte <methodname>regenerateId()</methodname> nicht verwendet werden, ausser der
erstere ruft den letzteren auf. Wenn sich ein Benutzer erfolgreich auf die Webseite
eingeloggt hat, sollte <methodname>rememberMe()</methodname> statt
<methodname>regenerateId()</methodname> verwendet werden.
</para>
<sect3
id="zend.session.global_session_management.session_identifiers.hijacking_and_fixation">
<title>Session-Entführung und Fixierung</title>
<para>
Das Vermeiden von
<ulink url="http://en.wikipedia.org/wiki/Cross_site_scripting">Seiten übergreifenden
Script (XSS) Gefährdungen</ulink> hilft bei der Vorbeugung von Session Entführungen.
Laut <ulink url="http://secunia.com/">Secunia's</ulink> 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
<acronym>AJAX</acronym> 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 <acronym>PHP</acronym> Session ändern, wenn der Entwickler den Wert für
die <code>save_path</code> Option richtig eingestellt hat.
</para>
<para>
Nur durch das Aufrufen von <methodname>Zend_Session::regenerateId()</methodname>,
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ß
(<methodname>regenerateId()</methodname>). 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
<code>use_only_cookies = off</code>).
</para>
<para>
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:
<itemizedlist mark='opencircle'>
<listitem>
<para>
Der Angreifer initiiert eine Session auf der Webseite um eine gültige
Session Id zu erhalten
</para>
</listitem>
<listitem>
<para>
Der Angreifer benutzt XSS Gefährdungen auf der Webseite um ein Cookie
auf dem Browser des Opfers mit der geichen, gültigen Session Id (z.b.
Session Fixierung), zu erstellen
</para>
</listitem>
<listitem>
<para>
Beide, das Opfer und der Angreifer kommen von der selben Proxy Farm
(z.B. wenn beide hinter der selben Firewall einer großen Firma, wie AOL,
sind)
</para>
</listitem>
</itemizedlist>
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.
</para>
<example
id="zend.session.global_session_management.session_identifiers.hijacking_and_fixation.example">
<title>Session Fixierung</title>
<programlisting language="php"><![CDATA[
$defaultNamespace = new Zend_Session_Namespace();
if (!isset($defaultNamespace->initialized)) {
Zend_Session::regenerateId();
$defaultNamespace->initialized = true;
}
]]></programlisting>
</example>
</sect3>
</sect2>
<sect2 id="zend.session.global_session_management.rememberme">
<title>>rememberMe(integer $seconds)</title>
<para>
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.
<methodname>Zend_Session::rememberMe()</methodname> 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 <code>remember_me_seconds</code>, welche durch
Verwendung von <methodname>Zend_Session::setOptions()</methodname> gesetzt werden kann.
Um zu helfen eine Session Fixierung/Entführung zu vereiteln, sollte diese Funktion
verwendet werden wenn sich ein Benutzer erfolgreich an der Anwendung authentifiziert hat
(z.B., durch ein "login" Formular).
</para>
</sect2>
<sect2 id="zend.session.global_session_management.forgetme">
<title>forgetMe()</title>
<para>
Diese Funktion ist das Gegenteil von <methodname>rememberMe()</methodname> durch
Schreiben eines Session Cookies das eine Lebenszeit hat die endet wenn der Benutzer
terminiert.
</para>
</sect2>
<sect2 id="zend.session.global_session_management.sessionexists">
<title>sessionExists()</title>
<para>
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 <classname>Zend_Session</classname> und
<classname>Zend_Session_Namespace</classname> Methoden.
</para>
</sect2>
<sect2 id="zend.session.global_session_management.destroy">
<title>destroy(bool $remove_cookie = true, bool $readonly = true)</title>
<para>
<methodname>Zend_Session::destroy()</methodname> entfernt alle deuerhaften Daten welche
mit der aktuellen Session verbunden sind. Aber es werden keine Variablen in
<acronym>PHP</acronym> verändert, so das die benannte Session (Instanzen von
<classname>Zend_Session_Namespace</classname>) lesbar bleibt. Es ein "Logout"
fertigzustellen, muß der optionale Parameter auf <constant>TRUE</constant> (standard)
gesetzt werden um auch das Session Id Cookie des User Agents zu löschen. Der optionale
<varname>$readonly</varname> Parameter entfernt die Möglichkeit neue
<classname>Zend_Session_Namespace</classname> Instanzen zu erstellen und für
<classname>Zend_Session</classname> in den Session Daten Speicher zu schreiben.
</para>
<para>
Wenn die Fehlermeldung "Cannot modify header information - headers already sent"
erscheint, sollte entweder die Verwendung von <constant>TRUE</constant> als Wert für das
erste Argument (die Entfernung des Session Cookies anfragen) vermieden werden, oder
in <link linkend="zend.session.global_session_management.headers_sent">diesem
Abschnitt</link> nachgesehen werden. Deswegen muß entweder
<methodname>Zend_Session::destroy(true)</methodname> aufgerufen werden bevor
<acronym>PHP</acronym> <acronym>HTTP</acronym> 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 <methodname>destroy()</methodname> zu Verhindern.
</para>
<note>
<title>Wirft</title>
<para>
Standardmäßig ist <varname>$readonly</varname> aktiviert, und weitere Aktionen
welche das Schreiben in den Session Daten Speicher beinhalten, werfen eine Ausnahme.
</para>
</note>
</sect2>
<sect2 id="zend.session.global_session_management.stop">
<title>stop()</title>
<para>
Diese Methode macht nicht mehr als ein Flag in <classname>Zend_Session</classname> 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 <classname>Zend_Session_Namespace</classname> Instanzen oder
<classname>Zend_Session</classname> 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.
</para>
</sect2>
<sect2 id="zend.session.global_session_management.writeclose">
<title>writeClose($readonly = true)</title>
<para>
Beendet die Session, schließt das schreiben und entfernt <varname>$_SESSION</varname>
vom Backend Speicher Mechanismus. Das vervollständigt die interne Transformation der
Daten auf diese Anfrage. Der optionale boolsche <varname>$readonly</varname> Parameter
kann den Schreibzugriff entfernen durch das werfen einer Ausnahme bei jedem Versuch in
eine Session durch <classname>Zend_Session</classname> oder
<classname>Zend_Session_Namespace</classname> zu schreiben.
</para>
<note>
<title>Wirft</title>
<para>
Standardmäßig ist <varname>$readonly</varname> aktiviert und weitere Aktionen welche
in den Session Daten Speicher schreiben werfen eine Ausnahme. Trotzdem könnten
einige besondere Anwendungen erwarten das <varname>$_SESSION</varname> beschreibbar
bleibt nachdem die Session mittels <methodname>session_write_close()</methodname>
beendet wurde. Obwohl das nicht die "beste Praxis" ist, ist die
<varname>$readonly</varname> für jene vorhanden die Sie benötigen.
</para>
</note>
</sect2>
<sect2 id="zend.session.global_session_management.expiresessioncookie">
<title>expireSessionCookie()</title>
<para>
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.
</para>
</sect2>
<sect2 id="zend.session.global_session_management.savehandler">
<title>setSaveHandler(Zend_Session_SaveHandler_Interface $interface)</title>
<para>
Die meisten Entwickler werden den Standardmäßigen Speicher Handle ausreichend finden.
Diese Methode bietet einen objekt-orientierten Wrapper für <ulink
url="http://php.net/session_set_save_handler"><methodname>session_set_save_handler()</methodname></ulink>.
</para>
</sect2>
<sect2 id="zend.session.global_session_management.namespaceisset">
<title>namespaceIsset($namespace)</title>
<para>
Diese Methode kann dazu verwendet werden um herauszufinden ob ein Session Namensraum
existiert, oder ob ein bestimmter Index in einem bestimmten Namensraum existiert.
</para>
<note>
<title>Wirft</title>
<para>
Eine Ausnahme wird geworfen wenn <classname>Zend_Session</classname> nicht als
lesbar markiert ist (z.B. bevor <classname>Zend_Session</classname> gestartet
wurde).
</para>
</note>
</sect2>
<sect2 id="zend.session.global_session_management.namespaceunset">
<title>namespaceUnset($namespace)</title>
<para>
<methodname>Zend_Session::namespaceUnset($namespace)</methodname> kann verwendet werden
um effektiv den kompletten Namensraum und dessen Inhalt zu entfernen. Wie mit allen
Arrays in <acronym>PHP</acronym>, 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. <methodname>namespaceUnset()</methodname> führt kein "tiefes"
entfernen/löschen von Inhalten eines Eintrages im Namensraum durch. Für eine
detailiertere Erklärung sollte im <acronym>PHP</acronym> Handbuch unter <ulink
url="http://php.net/references">Referenzen erklärt</ulink> nachgesehen werden.
</para>
<note>
<title>Wirft</title>
<para>
Eine Ausnahme wird geworfen wenn der Namensraum nicht beschreibbar ist (z.B. nach
<methodname>destroy()</methodname>).
</para>
</note>
</sect2>
<sect2 id="zend.session.global_session_management.namespaceget">
<title>namespaceGet($namespace)</title>
<para>
DEPRECATED: <methodname>getIterator()</methodname> in
<classname>Zend_Session_Namespace</classname> sollte verwendet werden. Diese Methode
gibt ein Array mit dem Inhalt von <varname>$namespace</varname> zurück. Wenn es logische
Gründe gibt diese Methode öffentlich aufrufbar zu lassen bitte ein Feedback auf die
<ulink url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink> Mailingliste
geben. Aktuell ist jede Anteilnahme an irgendeinem relevanten Thema sehr willkommen :)
</para>
<note>
<title>Wirft</title>
<para>
Eine Ausnahme wird geworfen wenn <classname>Zend_Session</classname> nicht als
lesbar markiert ist (z.B bevor <classname>Zend_Session</classname> gestartet wurde).
</para>
</note>
</sect2>
<sect2 id="zend.session.global_session_management.getiterator">
<title>getIterator()</title>
<para>
<methodname>getIterator()</methodname> kann verwendet werden, um ein Array zu erhalten,
das die Namen aller Namensräume enthält.
</para>
<note>
<title>Wirft</title>
<para>
Eine Ausnahme wird geworfen wenn <classname>Zend_Session</classname> nicht als
lesbar markiert ist (z.B. bevor <classname>Zend_Session</classname> gestartet
wurde).
</para>
</note>
</sect2>
</sect1>
|