Re: faking session data

>I have written numerous functions that check all user entered data on my
>site via POST and GET. My question is this: once my data checks out as
>being valid, I sometimes store it in SESSION as I move between pages,
>and eventually use the values in SESSION to update my database. Do I
>need to re-check the values in SESSION to make sure they are still valid
>before updating the database? In other words, I know session data
>resides on the server, but how possible/likely is it that a malicious
>user could fake session data after or in lieu of my initial error
>checks? All pages are protected by SSL if that makes any difference.

Ok, what is the threat here?

(1) Malicious admins of your server. You really can't protect
against them. They can modify your pages or corrupt the version
of PHP or edit files directly. They can probably modify your
database directly also.

(2) Session spoofing. Guessing a valid session is very difficult
to do because of the large number space used. It may well be easier
to guess the user's username/password, which is much more worthwhile
as that generally lasts much longer than a session. The most
practical session spoofs probably involve network sniffing, accessing
unattended computers, or using a URL posted by the legitimate user
including the session ID. (Partial) Defense against session spoofing:
time out sessions as quickly as practical without inconveniencing
legitimate users too much. Locking a session to an IP may inconvenience
or lock out legitimate users (e.g. AOL users or others whose ISPs
use round-robin proxies).

(3) Security holes in your PHP pages. If your pages can be convinced
to stuff invalid stuff into the session, you'll have corrupt data
in there. Check user inputs. Do not depend on Javascript for ANY
checking (it may be turned off, and manually asking for URLs with
telnet to the web server doesn't require it at all).

(4) Watch out for stale data. While you may have checked that what
you put into $_SESSION['article_id'] was a valid article *THEN*,
is it a valid article *NOW*? $_SESSION['article_id'] may not have
changed, but perhaps the article was deleted since then. If a user
keeps a session going for a long time (e.g. months), how often do
you check that he's still paid for his subscription, and hasn't
been deleted for abuse?

Gordon L. Burditt
.

Relevant Pages

  • Re: Lisp Web Development and Application State
    ... the hook for you to map back to wherever on the server you stored ... this can extend so far as to store *all* of the state ... a session or hack together a continuations/closures system that stores ... Write the "state" to the database in a single field. ...
    (comp.lang.lisp)
  • Re: Good Design Practice Question
    ... greatly increase the effeciency of your database hits. ... (if you forsee requiring more customers in a single context, then it may be better to make one hit immediately ... Ensure that your database server is configured to properly handle the largest load you expect. ... Session state is usefull for minimizing database hits and reducing the amount of times you have to "munge" the data before it's ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: distributed php
    ... >> By that I just mean, run on many computers... ... >> communication between threads is through the database anyway right (not ... > every server shares. ... Since PHP allows you to write your own session handler ...
    (comp.lang.php)
  • Re: Please! Doesnt anyone know a better way to do this?
    ... account, they need to automatically be directed to the page to enter data ... session variable on the Account page. ... I assume here that you're checking a database when the user attempts to ... When a new user attempts to login or clicks to register, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: security of sessions
    ... >Usernames and passwords should really be stored in a database, ... You do NOT want such information sitting around in a ... the data is sitting around *ON THE SERVER*. ... I don't particularly like PHP's default session handling of sticking ...
    (alt.php)