Guys, documentation is about giving people information that will help them solve problems, not about FUD. That was my original point about the php.ini entry. You can't just state that something is very very bad without giving workable solutins and alternatives.
Present ways of solving the problem and mention the security implications of each solution and thereby allow people to make informed decisions. The blurb below is better than the original php.ini warning, but it still does not really give the user a set of solutions. -Rasmus On Wed, 14 Aug 2002, Melvyn Sopacua wrote: > Inlined for the list. > > Index: reference.xml > =================================================================== > RCS file: /repository/phpdoc/en/reference/session/reference.xml,v > retrieving revision 1.8 > diff -u -r1.8 reference.xml > --- reference.xml 28 Jul 2002 14:04:32 -0000 1.8 > +++ reference.xml 14 Aug 2002 13:58:04 -0000 > @@ -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 <strong>not reliable</strong> 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 <strong>all</strong> > + 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; > > > > Met vriendelijke groeten / With kind regards, > > Webmaster IDG.nl > Melvyn Sopacua > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
