yohgaki Wed Aug 14 18:25:22 2002 EDT
Modified files:
/phpdoc/en/reference/session reference.xml
Log:
Added security description. Patch by <[EMAIL PROTECTED]>
Fixed trans-sid php.ini option description.
Index: phpdoc/en/reference/session/reference.xml
diff -u phpdoc/en/reference/session/reference.xml:1.8
phpdoc/en/reference/session/reference.xml:1.9
--- phpdoc/en/reference/session/reference.xml:1.8 Sun Jul 28 10:04:32 2002
+++ phpdoc/en/reference/session/reference.xml Wed Aug 14 18:25:22 2002
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="iso-8859-1"?>
-<!-- $Revision: 1.8 $ -->
+<!-- $Revision: 1.9 $ -->
<reference id="ref.session">
<title>Session handling functions</title>
<titleabbrev>Sessions</titleabbrev>
@@ -46,6 +46,41 @@
</note>
</section>
+ <section id="session.security">
+ <title>Sessions and security</title>
+ <para>
+ Using sessions, does not mean, you can be absolutely sure, that
+ the session data can only be viewed by that user. This is impor-
+ tant to keep in mind, when storing and displaying sensative
+ information. When storing data into a session, one should always
+ ask themselves, what the damage is, when somebody else views that
+ information, or how your application is affected when this session
+ is actually somebody else.
+ </para>
+ <para>
+ For instance, if somebody else takes a session, can he than post
+ a message in a forum, as that user and how big of a problem is that?
+ Or perhaps he can view what the original user was thinking of
+ ordering, because he gets access to that user's shopping cart.
+ Obviously for a flowershop, this is less dramatic, than for a
+ farmacy.
+ </para>
+ <para>
+ Therefore, when dealing with sensative information, there should
+ always be additional methods to decide whether it is a valid
+ session. Sessions are not reliable as a secure
+ authentication mechanism.
+ </para>
+ <para>
+ Sessions rely on the session ID, meaning one can 'steal' a session,
+ by stealing the session ID. This can be made harder, by using a cookie
+ specifically a session cookie, but does not in any way make it
+ impossible and still relies on the user closing all
+ browser windows, to expire the session cookie.
+ Besides that, even session cookies can be sniffed on a network or
+ logged by a proxyserver.
+ </para>
+ </section>
<section id="session.requirements">
&reftitle.required;
&no.requirement;
@@ -214,11 +249,22 @@
<listitem>
<simpara>
<literal>session.use_trans_sid</literal> whether transparent sid support
- is enabled or not if enabled by compiling with
- <link linkend="install.configure.enable-trans-sid">
- <literal>--enable-trans-sid</literal></link>.
- Defaults to <literal>1</literal> (enabled).
+ is enabled or not. Defaults to <literal>0</literal> (disabled).
</simpara>
+ <note>
+ <simpara>
+ For PHP 4.1.2 or less, it is enabled by compiling with
+ <link linkend="install.configure.enable-trans-sid">
+ <literal>--enable-trans-sid</literal></link>.
+ From PHP 4.2.0, trans-sid feature is always compiled.
+ </simpara>
+ <simpara>
+ URL based session management has addtional security risks compare to cookie
+based
+ session management. Users may send URL contains active session ID to their
+ friends by email or users may save URL contains session ID to their bookmark
+ and access your site with the same session ID always, for example.
+ </simpara>
+ </note>
</listitem>
<listitem>
<simpara>
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
