faking session data

[Marcus]

Hello all,

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.
Thanks in advance.

Marcus

[Kimmo Laine]

Re: faking session data

"Marcus" <JumpMan222@aol .com> kirjoitti
viestissä:fw1Re .598$sF6.421@ne wssvr24.news.pr odigy.net...[color=blue]
> Hello all,
>
> 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. Thanks in advance.
>[/color]

I'd say your session data is quite secure. Although, you might concider
these precautions:

http://www.ericisgreat.com/tinfoilhats/

--
SETI @ Home - Donate your cpu's idle time to science.
Further reading at <http://setiweb.ssl.ber keley.edu/>
Kimmo Laine <eternal.erecti onN0@5P4Mgmail. com>

[Bert Melis]

Re: faking session data

Marcus wrote:[color=blue]
> Hello all,
>
> 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.
> Thanks in advance.
>
> Marcus[/color]
The session data values are stored on the server. The session id however
is passed to the client. In the worst case, the client could fake the id
and hijack another session.

[Gordon Burditt]

Re: faking session data

>I have written numerous functions that check all user entered data on my[color=blue]
>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.[/color]

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