Reply to Re: To session or not to session

Your name:

Reply:


Posted by Matthew Weier O'Phinney on 04/06/05 04:54

* Jason Barnett <jason.barnett@telesuite.com>:
> mailings@vlaamse-kern.com wrote:
> > I have been doing all my design by using POST to transfer user data and GET
> > for user changeable variables.
> >
> > I would like to know what you guys think of using SESSION in production sites.
>
> SESSION is "A Good Thing".
>
> >
> > Right now I am giving a trust factor of 80% to POST and 0% on GET. What trust
> > factor should I apply to SESSION
>
> Why? Because it's more convenient (easier) to forge GET requests than
> it is to forge POST requests? Either route can get malicious code sent
> your way if you aren't careful, but given that most people are lazy then
> yes POST is less likely to be malformed.

*Always* treat as tainted *any* data received from the user. This is
simply a good security practice. POST and GET can both be manipulated by
the user to submit malicious requests.

> How much would I trust SESSION data? Probably about the same as POST.
> It's not as likely as GET to be abused, but it's still likely to happen.

Session data is entirely under your, the programmer's, control. As long
as you don't place any tainted data in your session, you can trust the
session completely. So, don't place unfiltered GET or POST data into the
session, and you'll likely be fine.

The prime reason to use a session is to keep data around that you don't
want to keep grabbing each time the user loads a page -- user
preferences (grabbed from the database, of course!), choices a user has
made over the course of the application (filtered, of course!), a count
of search results (to prevent additional hits to the database), etc. One
possible use is to keep track of where a user is in the application
program flow -- some applications have several screens that need to be
completed in a particular order; use of a session can help detect if the
user has attempted to go back to a previous screen.

In a word, a session is about keeping STATE in a stateless protocol
(http).

> > Should I implement a SESSIONless feature in case SESSION is not available?
>
> First of all, SESSION availability mostly depends on php.ini settings
> (it is enabled by default with PHP core).

Unless the person who compiled PHP for your machine or OS has explicitly
*disabled* session support, sessions will be available. Additionally,
all configuration options related to sessions are configurable at all
levels -- from php.ini down to the individual script; this means that,
assuming you have session support in your PHP binary (and in all
liklihoods you do), then you *will* be able to use them.

It's not unreasonable to assume session support is present in a PHP
installation; you may want to make a note that it's *required* if you
distribute your code, however -- in part to help those who install your
code debug for themselves.

> So for example if you are requiring COOKIES instead of allowing GET
> then you will run into some users that just don't accept cookies.
> And, you won't be able to use SESSION with those users.

That is not true. By setting session.use_trans_sid to a true value, you
can use sessions without cookies. If this is enabled, the session ID
will be passed via the URL or in hidden elements of forms if cookies are
not available on the client.

> If your SESSION infrastructure is a required part of using your site
> (e.g. it holds customer information) then you should require all users
> to start SESSIONs. But if the SESSION is storing non-essential
> information (e.g. tracking web traffic through your site) then you might
> just allow the user to browse without starting a session.

As I noted above, sessions are about storing application state in a
stateless protocol. If you have an application that needs to know
information about its own state, use a session.

> In any case, if you really want I suppose that you could propagate a
> SESSION id with hidden POST inputs instead of using COOKIE / GET.

As noted above, enable session.use_trans_sid, and this magic is done for
you.

--
Matthew Weier O'Phinney | WEBSITES:
Webmaster and IT Specialist | http://www.garden.org
National Gardening Association | http://www.kidsgardening.com
802-863-5251 x156 | http://nationalgardenmonth.org
mailto:matthew@garden.org | http://vermontbotanical.org

[Back to original message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация