Client-Side Session Data

[Sanders Kaufman]

When you have a session going, I know that PHP stores a session
token on the client, but does it keep the session *data* on the
client, as well?
Or is the session data being stored on the server, and just
indexed to the session token data?

[Rik]

Re: Client-Side Session Data

Sanders Kaufman wrote:

When you have a session going, I know that PHP stores a session
token on the client, but does it keep the session *data* on the
client, as well?
Or is the session data being stored on the server, and just
indexed to the session token data?

Standard is that 'session-data' (So, info in $_SESSION), is normally stored
in a file with the session-id. It is not available to the user, only their
session-id is.
--
Rik Wasmus

[Vincent Delporte]

Re: Client-Side Session Data

On Sun, 17 Dec 2006 23:33:23 GMT, Sanders Kaufman <bucky@kaufman. net>
wrote:

>When you have a session going, I know that PHP stores a session
>token on the client, but does it keep the session *data* on the
>client, as well?
>Or is the session data being stored on the server, and just
>indexed to the session token data?

If you use FireFox as your browser (Tools Cookie Editor), you'll
see that calling session_start() creates a cookie for your domain
called PHPSESSID, which disappears once the window is closed, but can
be made permanent by writting the ad hoc code in a PHP script on the
server. This session ID can then be read by server-side scripts to
identify the user whenever a page is called.

Generally speaking, no data appart from this should be located on the
client, as this makes it too easy for hackers to hit your server. If
you really must save more data in cookies, make sure they're
encrypted.

[seaside]

Re: Client-Side Session Data


Sanders Kaufman schrieb:

When you have a session going, I know that PHP stores a session
token on the client, but does it keep the session *data* on the
client, as well?
Or is the session data being stored on the server, and just
indexed to the session token data?

Only partly related, but probably helpful:

You can configure PHP to transparently inject your current session ID
in each and any URL, which you pass back as part of HTML code. If
correctly configured, PHP switches from cookie-based sessing ID storage
to auto-inject URL-based sessionID handling.

You need to compile PHP using --enable-trans-sid- set

[Toby Inkster]

Re: Client-Side Session Data

Sanders Kaufman wrote:

Or is the session data being stored on the server, and just
indexed to the session token data?

Yes.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[seaside]

Re: Client-Side Session Data


Toby Inkster schrieb:

Sanders Kaufman wrote:
>

Or is the session data being stored on the server, and just
indexed to the session token data?

>
Yes.

In this case, my hint regarding transparent URL-based session injection
might in deed be of interest.

[Sanders Kaufman]

Re: Client-Side Session Data

Toby Inkster wrote:

Sanders Kaufman wrote:
>

>Or is the session data being stored on the server, and just
>indexed to the session token data?

>
Yes.

Thanks to all of y'all.

[Vincent Delporte]

Re: Client-Side Session Data

On Sun, 17 Dec 2006 23:33:23 GMT, Sanders Kaufman <bucky@kaufman. net>
wrote:

>When you have a session going, I know that PHP stores a session
>token on the client, but does it keep the session *data* on the
>client, as well?

BTW, here's an article that just came out on dangerous ways to use
cookies:

How Not To Use Cookies

http://www.informit.com/guides/printerfriendly.asp?g=security&seqNum=232&rl=1

[Rik]

Re: Client-Side Session Data

Vincent Delporte wrote:

On Sun, 17 Dec 2006 23:33:23 GMT, Sanders Kaufman <bucky@kaufman. net>
wrote:

>When you have a session going, I know that PHP stores a session
>token on the client, but does it keep the session *data* on the
>client, as well?

>
BTW, here's an article that just came out on dangerous ways to use
cookies:
>
How Not To Use Cookies
>

http://www.informit.com/guides/printerfriendly.asp?g=security&seqNum=232&rl=1

Yup, it breaks down to some very simple rules:
1. HTTPS. No discussion, don't assume anything if you haven't got it.

2. Userdata belongs on the server, and stays on the server. Users know
their own password, emailadres, etc, and why transfer logged in status &
rights to and from the user? THe only place where they're needed is on the
server itself...

3. Using Cookies to keep track of logged in visitors ARE handy. They should
have random, unguessable values, and absolutely nothing to with their
actual information. Their just an random ID for you, the data that they
represent you can link on the server.

4. Do not keep users logged in. Session time out and cookies, if still
present, become useless for anyone trying to use it later. Explain that to
people who don't want to remember passwords.

5. Do not use the same ID purposefully twice (allthough it might occur,
chances should be very slim). A user logs in, and gets a random id.

6. And finally THE golden rule: never, ever trust user input. If you expect
a number, make sure it's a number. If you expect only certain characters,
make sure there are no other. If you cannot escape the fact that users have
to enter an unknown text, use the escaping tools of characters at your
disposal. Be very, very weary for SQL injection.

There are others, but these are the most important imho. There are others,
like keep a log what users do from what location, but that's usually only
needed when is has gone wrong, and you have to track it back, never save a
plain password, do not display errors in you code should it break for some
reason, error-displaying is for development, etc.
--
Rik Wasmus

[Vincent Delporte]

Re: Client-Side Session Data

On Tue, 19 Dec 2006 04:31:07 +0100, "Rik" <luiheidsgoeroe @hotmail.com>
wrote:

>Yup, it breaks down to some very simple rules:

Thanks for the great tips.

[Sanders Kaufman]

Re: Client-Side Session Data

Rik wrote:

Yup, it breaks down to some very simple rules:
1. HTTPS. No discussion, don't assume anything if you haven't got it.

Amen. That IS number one rule. Every other rule takes a
backseat to it.

No matter how tight your security is, if users login over HTTP,
their credentials can be tooooo easily intercepted - making all
other security measures worthless.

[Vincent Delporte]

Re: Client-Side Session Data

On Tue, 19 Dec 2006 09:01:31 GMT, Sanders Kaufman <bucky@kaufman. net>
wrote:

>No matter how tight your security is, if users login over HTTP,
>their credentials can be tooooo easily intercepted - making all
>other security measures worthless.

So HTTPS should be used when logging on and receiving the session ID
cookie, but from then, it's OK to use HTTP?

[Toby Inkster]

Re: Client-Side Session Data

Vincent Delporte wrote:

So HTTPS should be used when logging on and receiving the session ID
cookie, but from then, it's OK to use HTTP?

That will stop people stealing users login credentials, yes, *but* it's
still not completely secure, as the session ID could be intercepted and
used by an attacker.

You could make this slightly more secure by associating an IP address with
the session, and ending the session if the user's IP address changes,
though this may make things awkward for customers of certain ISPs such as
AOL that sit their customers behind a large pool of proxy servers.

If you're after the best security, keep using HTTPS for the entire session.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Sanders Kaufman]

Re: Client-Side Session Data

Vincent Delporte wrote:

On Tue, 19 Dec 2006 09:01:31 GMT, Sanders Kaufman <bucky@kaufman. net>
wrote:

>No matter how tight your security is, if users login over HTTP,
>their credentials can be tooooo easily intercepted - making all
>other security measures worthless.

>
So HTTPS should be used when logging on and receiving the session ID
cookie, but from then, it's OK to use HTTP?

That depends on what is happening from then.
ANY time sensitive data crosses the web, it should be over HTTPS
to prevent others from sniffing it out.

But HTTPS takes up more resources than regular HTTP. So where
sensitive data is not being shuffled about, HTTP is the better
choice.