sigmasternchen/php-doc-en
1
0
Fork 0
mirror of https://github.com/sigmasternchen/php-doc-en synced 2025-03-15 16:38:54 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Added security description. Patch by <msopacua@idg.nl>

Browse source 
Fixed trans-sid php.ini option description.


git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@92071 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Yasuo Ohgaki 2002-08-14 22:25:22 +00:00
parent 9bc397a9b1
commit cd0117c855
1 changed files with 51 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

56
reference/session/reference.xml
View file

@ -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>