Session IDs?

[Leif K-Brooks]

I'm working on a site, and I plan to use some sort of sessions for
login. To avoid issues with cookies, it will pass the session ID around
in a get parameter. However, if someone wants to end a link to their
friends, they may send the session ID as well by mistake. What should I
do to stop that?

 

[Beauregard T. Shagnasty]

Quoth the raven named Leif K-Brooks:

I'm working on a site, and I plan to use some sort of sessions for
login. To avoid issues with cookies, it will pass the session ID
around in a get parameter. However, if someone wants to end a link
to their friends, they may send the session ID as well by mistake.
What should I do to stop that?

Don't use a GET value, use a session variable, and check for it on the
other pages.

PHP:
$_SESSION['yourvarname'] = $_REQUEST['formfieldname'];

 

[Leif K-Brooks]

Quoth the raven named Leif K-Brooks:

I'm working on a site, and I plan to use some sort of sessions for
login. To avoid issues with cookies, it will pass the session ID
around in a get parameter. However, if someone wants to end a link
to their friends, they may send the session ID as well by mistake.
What should I do to stop that?

Don't use a GET value, use a session variable, and check for it on the
other pages.

PHP:
$_SESSION['yourvarname'] = $_REQUEST['formfieldname'];

Thanks, but I'm trying to set up my own session system using mod_python,
and I'm trying to figure out the best way to pass the ID around.

 

[Augustus]

Quoth the raven named Leif K-Brooks:

I'm working on a site, and I plan to use some sort of sessions for
login. To avoid issues with cookies, it will pass the session ID
around in a get parameter. However, if someone wants to end a link
to their friends, they may send the session ID as well by mistake.
What should I do to stop that?

Don't use a GET value, use a session variable, and check for it on the
other pages.

PHP:
$_SESSION['yourvarname'] = $_REQUEST['formfieldname'];

Thanks, but I'm trying to set up my own session system using mod_python,
and I'm trying to figure out the best way to pass the ID around.

There's only 4 ways you can move the data around the site... GET (in
querystring), POST (in form object), SESSION (in session object), COOKIE
(write a cookie to their 'pooter)

You don't want to do Cookie in the event they have cookies turned off... you
don't want to do Get because they could end up passing on their login info
to other users...

That leaves either POST or SESSION.... post is probably out of the question
because just to implement it would be not impossible but a real pain in the
ass and could cause a few problems here and there

So that leaves the Session Object

 

[Leif K-Brooks]

There's only 4 ways you can move the data around the site... GET (in
querystring), POST (in form object), SESSION (in session object), COOKIE
(write a cookie to their 'pooter)

So that leaves the Session Object

Right, and how do you propose passing a session ID around in the session
object I won't have until I can pass the session ID around?

 

[Toby A Inkster]

There's only 4 ways you can move the data around the site... GET (in
querystring), POST (in form object), SESSION (in session object), COOKIE
(write a cookie to their 'pooter)

What exactly you you thing this "session object" *is*???

I'll tell you: it's a user-friendly wrapper around cookies, usually with
the ability to drop back to using the query string for those browsers that
don't support cookies.

So no, the mysterious "session object" is not an option here because Leif
has already stipulated that he doesn't want to rely on cookies and has
some problems with the query string.

My advice to Leif would be twofold:

1. Provide an "e-mail this page to a friend" link. Make sure you have a
prominent "we will not sell your address to spammers" notice nearby.

2. Keep a record of the IP address with each session. If you get a request
for a session from a different IP address, then it's likely that this is a
different person, so redirect them to a different session.

This isn't foolproof, but it's a good start.

Even better would be to not avoid cookies: use cookies, fall back to query
string for browsers that don't do cookies, then implement #2 above only
for those browsers that are using the fall-back mechanism.

 

[Leif K-Brooks]

1. Provide an "e-mail this page to a friend" link. Make sure you have a
prominent "we will not sell your address to spammers" notice nearby.

Might work, but people might want to post the page to a forum or some such.

2. Keep a record of the IP address with each session. If you get a request
for a session from a different IP address, then it's likely that this is a
different person, so redirect them to a different session.

Interesting idea, but doesn't AOL change IP for every request? As much
as I hate AOL, I can't exclude its users.

Even better would be to not avoid cookies: use cookies, fall back to query
string for browsers that don't do cookies, then implement #2 above only
for those browsers that are using the fall-back mechanism.

Thanks, good idea. I think I'll try that.

 

[Toby A Inkster]

doesn't AOL change IP for every request?

I've checked my logs and yes, they do seem to. How irritating.

 

[rf]

I'm working on a site, and I plan to use some sort of sessions for
login. To avoid issues with cookies, it will pass the session ID around
in a get parameter. However, if someone wants to end a link to their
friends, they may send the session ID as well by mistake. What should I
do to stop that?

Been following this thread with interest

Question: Why exactly do you require me to "login" to the site?

Usually if I come across such a site I very quickly go elsewhere.

With all due respect if it is for something important like a banking site
then the very act of asking this question here immediatetly disqualifies you
from building such a site. Real security requires much more than just a
session cookie, SSL at least and all sorts of other things.

Cheers
Richard.

 

[Leif K-Brooks]

Question: Why exactly do you require me to "login" to the site?

It will be a community type site, with forums and such. I plan to make
everything which can not require login (viewing forums, for instance),
but things like posting will really need the user to login.

With all due respect if it is for something important like a banking site
then the very act of asking this question here immediatetly disqualifies you
from building such a site. Real security requires much more than just a
session cookie, SSL at least and all sorts of other things.

I'm not too worried about extreme security, there would only be virtual
game money at stake.

 

[Andy Dingley]

However, if someone wants to end a link to their
friends, they may send the session ID as well by mistake. What should I
do to stop that?

Look at how Amazon does it. You have to accept these session IDs
(because someone might invent them with evil intent, let alone
preserve them innocently). Your system _must_ be capable pf
recognising a false session ID (stale, wrong IP) and discarding it.

 

[Long]

:
: My advice to Leif would be twofold:
:
: 1. Provide an "e-mail this page to a friend" link. Make sure you have a
: prominent "we will not sell your address to spammers" notice nearby.
:
I agree here, but how would a site grab an email off a mailto: link? I don't think
it can so users need not worry. They just need to be educated of that fact.

: 2. Keep a record of the IP address with each session. If you get a request
: for a session from a different IP address, then it's likely that this is a
: different person, so redirect them to a different session.
:
Besides rotating IPs, users behind a proxy server may have the same IP so
it won't work in this situation either.

This is the classic "session spoofing" problem. I don't have a foolproof solution
either, but can offer the following advice.

Protect user data (personal info). You would want to tighten
security by password protecting sensitive pages. For example, have the
user re-enter his/her password on updating personal records.

You can make the user session temporary for each log in. Meaning the session
only last for the duration of the log in period. A new key will be given on subsequent
log in.

Also, your users need to be educated on the importance of their session key.
It is really their master key once they have logged in to your service. They should
be protecting it with their lives (figuratively speaking) and not spread it around.

Long

 

[Eric Bohlman]

Look at how Amazon does it. You have to accept these session IDs
(because someone might invent them with evil intent, let alone
preserve them innocently). Your system _must_ be capable pf
recognising a false session ID (stale, wrong IP) and discarding it.

"Stale" is the key here. If someone sends the URL to a friend, it's
unlikely that the friend will access it before the first party has finished
his session. Therefore, you just need to check whether a session ID is
currently active, and ignore it if it isn't.

 

[Leif K-Brooks]

"Stale" is the key here. If someone sends the URL to a friend, it's
unlikely that the friend will access it before the first party has finished
his session. Therefore, you just need to check whether a session ID is
currently active, and ignore it if it isn't.

What if a friend sends the link via Jabber or a lesser IM system? The
friend would most likely be there in under a minute.

 

[Zak McGregor]

I'm working on a site, and I plan to use some sort of sessions for
login. To avoid issues with cookies, it will pass the session ID around
in a get parameter. However, if someone wants to end a link to their
friends, they may send the session ID as well by mistake. What should I
do to stop that?

IMHO http authentication should be used in preference to other
methods - all of which are invariably workarounds or hacks.

Just my 2 ZA cents.

Ciao

Zak

 

[Adrienne]

Gazing into my crystal ball I observed Leif K-Brooks

I'm working on a site, and I plan to use some sort of sessions for
login. To avoid issues with cookies, it will pass the session ID around
in a get parameter. However, if someone wants to end a link to their
friends, they may send the session ID as well by mistake. What should I
do to stop that?

AFAIK the server assigns a unique session ID to each user, at least I know
that IIS does this.

This is what I do. First I test for cookies. I put the user's session ID
into a querystring in a link to another page. That other page tests if
the session ID of that page is the same as the querystring - if it is,
voila! you have a session cookie, if not, I have a message that advises
the user they need to, and how to, turn on _at least_ session cookies.

You could possibly do something similar. Have the person login and set a
session of loggedin to true, and pass that with a session ID in a
querystring. You would then have to check to see that the session ID was
the same as the querystring, and if it is not, change loggedin to false
and redirect to a login page.