>Subject: Re: Is session enough secure?
What is it you are trying to protect? If the answer is nuclear
launch codes or bank funds transfers between national banks, NO,
it's not secure enough. If the answer is "what I had for breakfast
on my 10th birthday", it is. Anything in between is a judgement
call. Credit card numbers, anything that involves spending actual
money (e-commerce site), social security numbers, and medical
information should be considered especially sensitive.
I have a page such that each user can see only a corresponding
(personal) part of the page. In the beginning I wanted to perform
initialization of users (by asking there names and passwords and
comparing them with names and passwords stored in database), than I
planed (if comparison was successful) to set a corresponding value of
variable $user_name and on the mentioned page with the help of the
"if"-operator to check whether value of $user_name allows to
display given part of the page.
If you use sessions, you set this in a SESSION variable. A SESSION
variable is held on the server where an ordinary web user can't get
to it (but the admin of the box can, so if this is on a hosted
server, trust your host).
However, I have realized that any user
can "by hand" set value of variable $user_name which (value) does
not correspond to the correct user name of this person.
A user cannot set a SESSION variable except by logging in honestly
or by hijacking the session of another user (and then, only under
the control of your code). Ways of hijacking the session of another
user include: guessing the session cookie, sniffing it on the
network, spyware or viruses on the user's computer, accessing the
user's computer while he's at lunch, etc. Expiring idle sessions
makes it harder to get a session cookie while it's still valid.
It also limits the damage if a user happens to post a URL with
his own session cookie in it.
Some of these methods could just as well get the information directly,
e.g. get the info out of the cached copy of the page the user looked
at on his own computer with the spyware or sniff the page while it
is being sent to the user.
A typical session ID is 128 bits long, encoded in hexadecimal.
At one guess per nanosecond, this could take up to 1e+22 years
to guess. And besides, your server isn't nearly fast enough
to handle one request per nanosecond.
Does it means
that only possible solution of this problem is to check name-password
pare (whether it (pare) exists in database) on each page?
Remember, if you're not using a secure server, sniffing the
name-password pair is about as easy as sniffing the session cookie,
but it's much more damaging (sessions expire in maybe hours (you
control this), username/passwords combinations stay around for months).
Gordon L. Burditt
