cvs: phpdoc-de /reference/session reference.xml

samesch Fri Aug 16 12:23:32 2002 EDT Modified files: /phpdoc-de/reference/session reference.xml Log: syncing with EN-Rev. 1.9 Index: phpdoc-de/reference/session/reference.xml diff -u phpdoc-de/reference/session/reference.xml:1.5 phpdoc-de/reference/session/reference.xml:1.6 --- phpdoc-de/reference/session/reference.xml:1.5 Thu Aug 8 18:34:35 2002 +++ phpdoc-de/reference/session/reference.xml Fri Aug 16 12:23:32 2002 @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="iso-8859-1"?> -<!-- $Revision: 1.5 $ --> -<!-- EN-Revision: 1.8 Maintainer: samesch Status: ready --> +<!-- $Revision: 1.6 $ --> +<!-- EN-Revision: 1.9 Maintainer: samesch Status: ready --> <reference id="ref.session"> <title>Session Funktionen</title> <titleabbrev>Sessions</titleabbrev> @@ -52,6 +52,46 @@ </note> </section> + <section id="session.security"> + <title>Sessions and security</title> + <para> + Wenn Sie Sessions verwenden, bedeutet das nicht, dass Sie + absolut sicher sein können, dass die Session-Daten nur vom + jeweiligen Benutzer gesehen werden können. Es ist wichtig, dass + Sie beim Speichern und Anzeigen sensibler Daten daran denken. + Wenn Sie Daten in einer Session speichern, sollten Sie sich immer + fragen, wie groß der Schaden ist, wenn jemand anderes diese + Informationen sieht oder inwieweit Ihre Anwendung davon betroffen + ist, wenn die Session in Wirklichkeit von jemand anderem benutzt + wird. + </para> + <para> + Kann zum Beispiel jemand, der eine Session übernimmt, als dieser + Benutzer eine Nachricht an ein Forum senden und stellt das ein + großes Problem dar? Oder vielleicht kann er sehen, was der + ursprüngliche Benutzer zu bestellen beabsichtigte, weil er + Zugriff auf den Einkaufswagen dieses Benutzers bekommt. Für einen + Blumenladen wäre das offensichtlich weniger dramatisch als für + eine Apotheke. + </para> + <para> + Deshalb sollte es beim Umgang mit sensiblen Daten immer + zusätzliche Methoden geben, mit denen festgestellt werden kann, + ob es sich um eine gültige Session handelt. Sessions sind als + Mechanismus für sichere Authentifizierung nicht verlässlich. + </para> + <para> + Sessions vertrauen auf die Session-ID, was bedeutet, dass eine + Session 'gestohlen' werden kann, indem die Session-ID gestohlen + wird. Dies kann durch Verwendung eines Cookies, speziell eines + Session-Cookies, erschwert werden, aber das macht es keinesfalls + unmöglich und stützt sich immer noch darauf, dass der Benutzer + alle Browserfenster schließt, damit das Cookie verfällt. Außerdem + können auch Session-Cookies in einem Netzwerk ausgeschnüffelt + werden oder von einem Proxyserver protokolliert werden. + </para> + </section> + <section id="session.requirements"> &reftitle.required; &no.requirement; @@ -229,13 +269,27 @@ </listitem> <listitem> <simpara> - <literal>session.use_trans_sid</literal> bestimmt, wenn - mit - <link linkend="install.configure.enable-trans-sid"><literal>--enable-trans-sid</literal></link> - kompiliert wurde, ob transparente SID-Unterstützung aktiviert - ist oder nicht. Grundeinstellung <literal>1</literal> - (aktiviert). - </simpara> + <literal>session.use_trans_sid</literal> bestimmt ob + transparente SID-Unterstützung aktiviert ist oder nicht. + Grundeinstellung <literal>0</literal> (deaktiviert). + </simpara> + <note> + <simpara> + In PHP 4.1.2 oder darunter wird sie durch compilieren mit + <link + linkend="install.configure.enable-trans-sid"><literal>--enable-trans-sid</literal></link> + aktiviert. Ab PHP 4.2.0 ist das Feature trans-sid immer + eincompiliert. + </simpara> + <simpara> + URL-basiertes Session-Management hat im Vergleich zu + Cookie-basiertem Session-Management zusätzliche + Sicherheitsrisiken. Benutzer können zum Beispiel eine URL, + die eine aktive Session-ID enthält, per Email an Freunde + schicken oder in ihren Bookmarks speichern und immer mit der + selben Session-ID auf Ihre Seite zugreifen. + </simpara> + </note> </listitem> <listitem> <simpara>