Perl & Sessions?

[Malcolm Dew-Jones]

Steve (another one) ([email protected]) wrote:
: Malcolm Dew-Jones wrote:
: > Greg Klinedinst ([email protected]) wrote:
: > : On Wed, 03 Mar 2004 21:07:58 +0100, Vetle Roeim <[email protected]>
: > : wrote:
: >
: > : > If you put the session id in the URL, your system may be vulnerable
: > : > to session hijacking.
: > : >

: OK I'm convinced that I should re-examine my approach - I will consider
: cookies for future projects.

(There's no law that says you must, that was just me $0.02.)

: However, can I please nail-down the
: comments such as:

: >Caching can mean that old values are passed around, whereas
: >the cookie is always up to date.

If the user requests a previously seen page they may get a cached page.

If that cached page has a hidden field, then responding to the page (i.e.
pressing a submit) button will send the cached hidden value back to your
server.

If that value was instead passed as a cookie, then the value sent back
would be the most recently set cookie value, not a cached value.

This means you don't have to worry about setting extra headers to disable
caching, which means less programming work for you.

It also allows the caching to speed up your web site for both the user
(who doesn't have to wait for a page to download again), and your server
which doesn't have to send the same page to them again.


: >If you put the session id in the URL, your system may be
: >vulnerable to session hijacking.

: These are simply not issues with properly desgined session id's which
: are properly managed by the application. This proper design needs only
: to be done once !

The issue with session ids in the url is that if the user visits a
different site then the referrer header will tell that other site what
session ids are currently valid to access your site. If you use nothing
but the session id then that other site will be able to use that sessionid
to access your site with the login credentials of the original user.

One way to prevent this is to include additional information in the web
page as a cross reference to the session id. But how is that cross
reference supposed to be passed? You can't put it in the url because then
it would have the same issue as the original sesssion id. If you are
using forms and can pass it as a posted value, then one must ask, why
include the session id in the url in the first place? Likewise, if you
include cookie information then why not simply put the session id in the
cookie in the first place?

You might try and cross reference the session id with an ip address, but
because of proxies, this doesn't work very well.


: No system can guard against a user wandering off with a session underway
: and a baddy coming along and taking it over before the application
: times-out the session whether via cookie or POSTed id.

The question is just how easily the baddy can get the session id.
Suppose a baddy wanted to get credit card data, and has a few resources to
apply. They could easily set up a very legit, useful site, like a
dictionary that many people might want to visit while reading other pages,
and then watch for session ids associated with sites that use credit
cards. There would be no way for anyone to detect that, since they won't
have hacked into anything to do it.

 

[Vetle Roeim]

* Ben Morrow

...but may well still choose not to, as they don't trust the site in
question. Speaking as someone who refuses cookies by default, I don't
think that relying on them for session IDs is a good idea.

Hmmmm.. Well... It's your right to refuse cookies, of course.

If the ID is in a field (GET or POST) I have much more control over
what you track and what you don't.

Well... Using session IDs in GET requeste (i.e. they're in the URL)
may be a bad idea, as they may be sent to external sites through the
referer HTTP header. I mentioned this in another post.

Also note that (I don't know if it ever came to anything) there was talk
of an EU directive banning cookies, as an invasion of privacy...

Banning them sounds a bit too hars. But I'm all for it if we can
create another method for passing session IDs around.

 

[Vetle Roeim]

* Alan J. Flavell

"most users" aren't Perl programmers. So if you're only interested
in "most users", why are you here? ;-))

Good point.

I think you're missing a significant comma in that sentence!!!

Er... Yes. It should have been "and those who don't, know what
they're doing".

Commas are fun.

"Can", certainly, but if it's not of proven value to them, they'll
maybe go somewhere else instead...

Yes, exactly.

If they "require" it, then I'll surely go somewhere else. If they
bother to explain why it's going to benefit *me* (i.e more than it
benefits *them*), then I'd be happy to consider it.

Yes, exactly! I agree with you.

The clue here is _why_ cookies are used, and _what_ they're used
for. For instance: I'm currently working on a content management
system, and users logging in in the administrative interface get a
cookie with a session ID. In this case it serves a *purpose*.

The benefit is obvious... The customer has paid loads of cash for
our system, and has to enable cookies to use the administrative
interface.

In other cases cookies may be pointless, of course. So go somewhere
else... I'm all for that.

 

[Bart Lateur]

Not as easily as they can with hidden values The user can save the
page, alter the hidden value, then submit the page - simple

Alter the hidden value... to what?

Valid session ID's should be sparse, not just sequential numbers, and
therefor very hard to guess.

The problem I see with forms, if it's a problem, is that you can save a
form to file, open it on another browser, and "continue" the session.

If the session ID is part of the URL, then saving it as a bookmark, or
mailing somebody the URL, will let somebody continue the session at a
later time.

Cookies are a little bit more private.