[PHP-DOC] cvs: phpdoc /en/reference/session reference.xml From: Yasuo Ohgaki (yohgaki <email protected>)
Date: 08/14/02

yohgaki Wed Aug 14 18:25:22 2002 EDT

  Modified files:
    /phpdoc/en/reference/session reference.xml
  Log:
  Added security description. Patch by <msopacua <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