Perl & Sessions?

  • Thread starter Thomas Deschepper
  • Start date
T

Thomas Deschepper

I would like to make a perl script that lets the user log in and checks if
the username and password are correct. After authentication, I want to
track that user. I understand that HTTP is "stateless", so I read
something about sessions and how to implent them (GET, cookies, hidden
fields).

But I don't really understand the whole process. After the user logs in,
do I have to produce a unique hash or something like that??

Can someone explain this to me? I've also read the docs about CGI::Session.

Thanks in advance,

mvg Thomas Deschepper
 
J

James Willmore

I would like to make a perl script that lets the user log in and checks if
the username and password are correct. After authentication, I want to
track that user. I understand that HTTP is "stateless", so I read
something about sessions and how to implent them (GET, cookies, hidden
fields).

But I don't really understand the whole process. After the user logs in,
do I have to produce a unique hash or something like that??

Can someone explain this to me? I've also read the docs about CGI::Session.

Have a look at ...
http://www.stonehenge.com/merlyn/WebTechniques/col61.html

There are several ways to deal with sessions. However, I find the above
URL one of the better ways to do so. Basically, you want to make sure
that what the user has as credentials is the same thing the server sees as
valid credentials. One of the better ways to do this is using cookies.
That's what is explained in better detail in the above URL. It is,
however, not the only way to do it :)

HTH
--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
"Whatever the missing mass of the universe is, I hope it's not
cockroaches!" -- Mom
 
S

Steve (another one)

James said:
Have a look at ...
http://www.stonehenge.com/merlyn/WebTechniques/col61.html

There are several ways to deal with sessions. However, I find the above
URL one of the better ways to do so. Basically, you want to make sure
that what the user has as credentials is the same thing the server sees as
valid credentials. One of the better ways to do this is using cookies.
That's what is explained in better detail in the above URL. It is,
however, not the only way to do it :)

HTH
After a sucessful login I usually send a hard-to-guess string in a
hidden field and then use this to identify the user. The value is held
in a table with a date/time stamp that I update whenever I hear from the
user, or delete after a given period of non-use or a log-off. This
allows the user to do what they like while the identifier is valid -
including reject cookies and maintain multiple sessions. It seems
simpler than cookies and just as secure. Or am I missing something ?

Steve
 
V

Vetle Roeim

* (e-mail address removed)
[...]
After a sucessful login I usually send a hard-to-guess string in a
hidden field and then use this to identify the user. The value is held
in a table with a date/time stamp that I update whenever I hear from
the user, or delete after a given period of non-use or a log-off. This
allows the user to do what they like while the identifier is valid -
including reject cookies and maintain multiple sessions. It seems
simpler than cookies and just as secure. Or am I missing something ?

You have it in a hidden field? Are all requests to your system POST
requests, then?

With cookies you don't have to pass the value around everywhere, as
it's done for you.
 
J

James Willmore

After a sucessful login I usually send a hard-to-guess string in a
hidden field and then use this to identify the user. The value is held
in a table with a date/time stamp that I update whenever I hear from the
user, or delete after a given period of non-use or a log-off. This
allows the user to do what they like while the identifier is valid -
including reject cookies and maintain multiple sessions. It seems
simpler than cookies and just as secure. Or am I missing something ?

Hidden fields are not *really* hidden and can be altered by the user.
This is why *most* who do CGI applications don't use hidden fields at all.

And, if you *read* the URL, you would see *why* the author does what he
does. Basically, one single cookie is used. This cookie contains an MD5
hash (which is, in theory, hard to recontruct). This session id is match
to a file on the server. You can place "stuff" in the file, but I don't
see it as required.

"Logging off" is a real mis-conception. The session between the browser
and the server is closed after information is sent to and fro - meaning,
there is no state like telnet or ftp. Because HTTP is stateless, there
really is no logging in or logging out per se. Which is why some
identifier between the browser and the server is created.

The bottom line with this whole thing is really rather simple - create an
identifer unique for the browser that can can be matched in some way on
the server. The identifier *must* be something the user *can not* alter
(at least, not easily). Hidden fields is *not* the way to do it.

You can go crazy and store all types of information in a database, but I
don't see the point unless you need security "bumped up a notch".

There are Perl modules that can handle sessions, but it's really up to the
programmer to figure out the requirements and needs of the application.

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Real Programs don't use shared text. Otherwise, how can they use
functions for scratch space after they are finished calling them?
 
V

Vetle Roeim

* James Willmore
[...]
Hidden fields are not *really* hidden and can be altered by the user.
This is why *most* who do CGI applications don't use hidden fields at all.

But he has basically the same functionality as cookies, only the
session id is in a form element. Users can alter their cookie values
too, you know...


[...]
The bottom line with this whole thing is really rather simple - create an
identifer unique for the browser that can can be matched in some way on
the server. The identifier *must* be something the user *can not* alter
(at least, not easily). Hidden fields is *not* the way to do it.

It's possible to fake cookie values... Session hijacking is still
possible, whether the session id is in a form element or in a
cookie.


[...]
 
S

Steve (another one)

James said:
Hidden fields are not *really* hidden and can be altered by the user.
This is why *most* who do CGI applications don't use hidden fields at all.

Of course not, but then neither are cookies. As long as a user can't
create a string which happens to be a current session id (I also use an
MD5 hash), they work. I am not arguing in favour of the method I
outlined - I want to understand *why* most use cookies.
And, if you *read* the URL, you would see *why* the author does what he
does. Basically, one single cookie is used. This cookie contains an MD5
hash (which is, in theory, hard to recontruct). This session id is match
to a file on the server. You can place "stuff" in the file, but I don't
see it as required.
I did read the URL which is what prompted my response. I didn't see
anything that made the cookie approach simpler than passing a session
identifier. The down side is that many users reject cookies.
"Logging off" is a real mis-conception. The session between the browser
and the server is closed after information is sent to and fro - meaning,
there is no state like telnet or ftp. Because HTTP is stateless, there
really is no logging in or logging out per se. Which is why some
identifier between the browser and the server is created.

Again, of course this is true. By logging off I mean making the session
id no longer valid.
The bottom line with this whole thing is really rather simple - create an
identifer unique for the browser that can can be matched in some way on
the server. The identifier *must* be something the user *can not* alter
(at least, not easily). Hidden fields is *not* the way to do it.

Sorry to be stupid here, but why is an MD5 digest in a hidden field
insecure ? If the user changes it they create an invalid session id and
are rejected. To guess a valid session id is likely to be *much* harder
than guessing a valid username and password. So I would suggest that it
doesn't matter if the user can easily alter it. Its not as if it could
be altered accidentally !

Thanks

Steve
 
V

Vetle Roeim

* Scott Bryce
[...]
The reason I lean toward URL munging/hidden fields is that users can
choose not to accept cookies. If a user does not accept your cookie,
you cannot identify the session later on. The user does not have the
option of rejecting your hidden fields.

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

If the user goes to a page in your system (with the session id in
the URL) and clicks a link to an external site, the session id will
appear in the referer-header that is sent to the external site.

Sverre H. Husebys "Innocent Code" covers this, and much more.
<URL:http://innocentcode.thathost.com/>


[...]
 
M

Malcolm Dew-Jones

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.
: >
: > If the user goes to a page in your system (with the session id in
: > the URL) and clicks a link to an external site, the session id will
: > appear in the referer-header that is sent to the external site.
: >
: > Sverre H. Husebys "Innocent Code" covers this, and much more.
: > <URL:http://innocentcode.thathost.com/>

: The user can find out their own session ID in all cases, since in all
: cases it is data they(the client) are sending to your server. The only
: real difference is that with the URL/hidden vars way you don't need to
: worry about the client rejecting cookies. Also the URL way(GET)
: probably isn't ideal b/c the URL has a maximum length, so hidden
: vars(POST) are best IMHO. You just have to make sure that they cannot
: guess how you created the session ID, and make sure you expire session
: IDs in your DB.


Cookies are handled by the browser, so they may be easier to code. You
set them just once, and then read them as necessary, no need to ever
accomodate them in your pages. In particular your web site can use static
pages when ever it is convenient, and the context is not lost.

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

A cookie can be changed independently of the pages (which can be good or
bad).

Personally, I have set up pages that used nothing but hidden fields, but I
don't do it anymore. I have found that a cookie is just too much easier
to use (unless you pay me well - then I would of course) mostly because
you only ever use them when you need them, whereas a hidden field must
always be passed around somehow, which limits the techniques available for
generating pages, links, and etc.

Someone mentioned the problem of the referrer header passing information
to unrelated sites, and therefore links should not contain session ids. I
just thought I would reiterate that, because if you know someones session
id it can be trivial to play in their session.

As for user's turning cookies off, this is no different than (for example)
selling an item with a picture and trying to accomodate a person with a
text browser - at some point you just have to say "sorry", you need a
certain base level to access all the features of this site. Same with
Javascript. I understand the reluctance of some people to turn it on, but
at some point the user needs to decide if they want to interact with you,
kind of like deciding whether they will bite the bullet and key in their
credit card number - at some point they must do what _you_ want if they
want to interact with your system.
 
S

Steve (another one)

Malcolm said:
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.
: >
: > If the user goes to a page in your system (with the session id in
: > the URL) and clicks a link to an external site, the session id will
: > appear in the referer-header that is sent to the external site.
: >
: > Sverre H. Husebys "Innocent Code" covers this, and much more.
: > <URL:http://innocentcode.thathost.com/>

: The user can find out their own session ID in all cases, since in all
: cases it is data they(the client) are sending to your server. The only
: real difference is that with the URL/hidden vars way you don't need to
: worry about the client rejecting cookies. Also the URL way(GET)
: probably isn't ideal b/c the URL has a maximum length, so hidden
: vars(POST) are best IMHO. You just have to make sure that they cannot
: guess how you created the session ID, and make sure you expire session
: IDs in your DB.


Cookies are handled by the browser, so they may be easier to code. You
set them just once, and then read them as necessary, no need to ever
accomodate them in your pages. In particular your web site can use static
pages when ever it is convenient, and the context is not lost.

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

A cookie can be changed independently of the pages (which can be good or
bad).

Personally, I have set up pages that used nothing but hidden fields, but I
don't do it anymore. I have found that a cookie is just too much easier
to use (unless you pay me well - then I would of course) mostly because
you only ever use them when you need them, whereas a hidden field must
always be passed around somehow, which limits the techniques available for
generating pages, links, and etc.

Someone mentioned the problem of the referrer header passing information
to unrelated sites, and therefore links should not contain session ids. I
just thought I would reiterate that, because if you know someones session
id it can be trivial to play in their session.

As for user's turning cookies off, this is no different than (for example)
selling an item with a picture and trying to accomodate a person with a
text browser - at some point you just have to say "sorry", you need a
certain base level to access all the features of this site. Same with
Javascript. I understand the reluctance of some people to turn it on, but
at some point the user needs to decide if they want to interact with you,
kind of like deciding whether they will bite the bullet and key in their
credit card number - at some point they must do what _you_ want if they
want to interact with your system.



--
Web Work Wanted, Perl Projects Programmed, Database Development Done.

I'm looking for telecommute projects. (Paying that is, various
arrangements possible.)


OK I'm convinced that I should re-examine my approach - I will consider
cookies for future projects. 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.
and

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 !

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.

Steve
 
J

James Willmore

* James Willmore
[...]
Hidden fields are not *really* hidden and can be altered by the user.
This is why *most* who do CGI applications don't use hidden fields at all.

But he has basically the same functionality as cookies, only the
session id is in a form element. Users can alter their cookie values
too, you know...

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

Basicily, two things to remember about security ....
- the human interface *is* the weakest link in *any* security model
- security is to keep honest people honest; if someone *really* wants to
get around security you have set up, they will find a way (usually,
through the human interface :) )

So, in the end, nothing says you *have* to favor cookies over hidden
fields, but, IMHO, why make it easier for the human interface to break
down the security you have set up. With cookies, it's more of a chore to
change anything versus hidden fields which is rather trivial and
*anyone* can do it with relative ease.

Just my $0.02
[...]
The bottom line with this whole thing is really rather simple - create an
identifer unique for the browser that can can be matched in some way on
the server. The identifier *must* be something the user *can not* alter
(at least, not easily). Hidden fields is *not* the way to do it.

It's possible to fake cookie values... Session hijacking is still
possible, whether the session id is in a form element or in a
cookie.

Ah ... now we're getting into using other mechanisms to prevent this from
occuring - which are done on the server side. Like, storing the
HTTP referer and/or remote host value(s) in the session id file. This,
again, can be circumvented.

As interesting as this thread is, it's now getting to the point that it's
not Perl :)

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Health nuts are going to feel stupid someday, lying in hospitals
dying of nothing. -- Redd Foxx
 
S

Steve (another one)

James said:
* James Willmore
[...]
After a sucessful login I usually send a hard-to-guess string in a
hidden field and then use this to identify the user. The value is held
in a table with a date/time stamp that I update whenever I hear from the
user, or delete after a given period of non-use or a log-off. This
allows the user to do what they like while the identifier is valid -
including reject cookies and maintain multiple sessions. It seems
simpler than cookies and just as secure. Or am I missing something ?

Hidden fields are not *really* hidden and can be altered by the user.
This is why *most* who do CGI applications don't use hidden fields at all.

But he has basically the same functionality as cookies, only the
session id is in a form element. Users can alter their cookie values
too, you know...


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

Basicily, two things to remember about security ....
- the human interface *is* the weakest link in *any* security model
- security is to keep honest people honest; if someone *really* wants to
get around security you have set up, they will find a way (usually,
through the human interface :) )

So, in the end, nothing says you *have* to favor cookies over hidden
fields, but, IMHO, why make it easier for the human interface to break
down the security you have set up. With cookies, it's more of a chore to
change anything versus hidden fields which is rather trivial and
*anyone* can do it with relative ease.

Just my $0.02

[...]
The bottom line with this whole thing is really rather simple - create an
identifer unique for the browser that can can be matched in some way on
the server. The identifier *must* be something the user *can not* alter
(at least, not easily). Hidden fields is *not* the way to do it.

It's possible to fake cookie values... Session hijacking is still
possible, whether the session id is in a form element or in a
cookie.


Ah ... now we're getting into using other mechanisms to prevent this from
occuring - which are done on the server side. Like, storing the
HTTP referer and/or remote host value(s) in the session id file. This,
again, can be circumvented.

As interesting as this thread is, it's now getting to the point that it's
not Perl :)



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

Aaaaarrrrgghh this is going nowhere - changing the hidden value achieves
nothing. You might as well say that a username/password is insecure
because the user can enter anything they like.
 
J

James Willmore

Aaaaarrrrgghh this is going nowhere - changing the hidden value achieves
nothing. You might as well say that a username/password is insecure
because the user can enter anything they like.

Well, I wasn't looking for an argument - discussion, yes ... argument, no.
Sorry it appears that way :-(

I agree with you that, if it's a session id in the hidden field that
changing it *may* not do anything but lock out the user (or bad guy).
However, consider this - I have a valid session id in my possession. I
have saved the page that I want to exploit on ye olde hard drive. Now,
it's a trival task to changed the hidden value on the page to match the
valid session id and, bang, I've just hijacked a session.

This does not take into account that you have saved the remote host value
somewhere and are checking this value againist where I'm coming from. Or
using other methods to strengthen security around the site.

The point I was trying to make is simple - hidden values are trival to
change - cookies are not as trivial.

Feel free to disagree. It's really just my experience on the
matter and is not meant to be godspell. However, this discussion is
better left to another group - since it really has nothing to do with Perl :)

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
"Being disintegrated makes me ve-ry an-gry!" <huff, huff>
 
V

Vetle Roeim

* Greg Klinedinst
The user can find out their own session ID in all cases, since in all
cases it is data they(the client) are sending to your server. The only
real difference is that with the URL/hidden vars way you don't need to
worry about the client rejecting cookies.

I don't really see this as a problem... Most users have cookies
enabled, and those who don't know what they're doing and can enable
cookies for sites that require it.


[...]
 
B

Ben Morrow

Vetle Roeim said:
I don't really see this as a problem... Most users have cookies
enabled, and those who don't know what they're doing and can enable
cookies for sites that require it.

....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. If the ID is
in a field (GET or POST) I have much more control over what you track
and what you don't.

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...

Ben
 
V

Vetle Roeim

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

Well... In Opera it's easier to edit cookie values than
save-edit-submit. It probides an interface for editing cookie
values.

Personally, I prefer using cookies, but the security gained by using
cookies is IMHO not significant... The practical benefits are
greater.


[...]
 
A

Alan J. Flavell

I don't really see this as a problem... Most users have cookies
enabled,

"most users" aren't Perl programmers. So if you're only interested
in "most users", why are you here? ;-))
and those who don't know what they're doing

I think you're missing a significant comma in that sentence!!!
and can enable cookies

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

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.

cheers
 
A

Alan J. Flavell

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...

IANAL, but as I understood it, what is ruled out is attempting to set
a cookie without any explanation of what it's used for.

Google suggests http://www.iabuk.net/index.php?class=news&view=801

One site insisted I had to accept its cookie before it would even
let me read their policy statement! You can guess what I did next...
 
A

Alan J. Flavell

On Thu, 4 Mar 2004, Alan J. Flavell wrote:

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

I'm rightly rebuked by a 3rd party in email: whereas the sentence
really *does* call for something to disambiguate it, the truth is that
a comma wouldn't be the proper way to do it.

Point taken, and I'm happy to correct the record. (Apologies for the
off-topic detail.)
 
C

ctcgag

Scott Bryce said:
The reason I lean toward URL munging/hidden fields is that users can
choose not to accept cookies. If a user does not accept your cookie, you
cannot identify the session later on. The user does not have the option
of rejecting your hidden fields.

If the user rejects the cookies, that is their decision--presumably they
made it for a reason. Why should I set about circumventing their decision
by using hidden fields?


Xho
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top