Perl & Sessions?

Discussion in 'Perl Misc' started by Thomas Deschepper, Mar 3, 2004.

  1. 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
    Thomas Deschepper, Mar 3, 2004
    #1
    1. Advertising

  2. On Wed, 03 Mar 2004 14:42:19 +0100, Thomas Deschepper wrote:

    > 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
    James Willmore, Mar 3, 2004
    #2
    1. Advertising

  3. James Willmore wrote:
    > On Wed, 03 Mar 2004 14:42:19 +0100, Thomas Deschepper wrote:
    >
    >
    >>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

    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
    Steve (another one), Mar 3, 2004
    #3
  4. Thomas Deschepper

    Vetle Roeim Guest

    *
    [...]
    > 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.

    --
    #!/usr/bin/vr
    Vetle Roeim, Mar 3, 2004
    #4
  5. On Wed, 03 Mar 2004 14:53:52 +0000, Steve (another one) wrote:
    > James Willmore wrote:
    >> On Wed, 03 Mar 2004 14:42:19 +0100, Thomas Deschepper wrote:


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

    > 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?
    James Willmore, Mar 3, 2004
    #5
  6. Thomas Deschepper

    Vetle Roeim Guest

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


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


    [...]

    --
    #!/usr/bin/vr
    Vetle Roeim, Mar 3, 2004
    #6
  7. James Willmore wrote:
    > On Wed, 03 Mar 2004 14:53:52 +0000, Steve (another one) wrote:
    >
    >>James Willmore wrote:
    >>
    >>>On Wed, 03 Mar 2004 14:42:19 +0100, Thomas Deschepper wrote:

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

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


    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
    Steve (another one), Mar 3, 2004
    #7
  8. Thomas Deschepper

    Vetle Roeim Guest

    * 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/>


    [...]
    --
    #!/usr/bin/vr
    Vetle Roeim, Mar 3, 2004
    #8
  9. Greg Klinedinst () wrote:
    : On Wed, 03 Mar 2004 21:07:58 +0100, Vetle Roeim <>
    : 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.)
    Malcolm Dew-Jones, Mar 4, 2004
    #9
  10. Malcolm Dew-Jones wrote:
    > Greg Klinedinst () wrote:
    > : On Wed, 03 Mar 2004 21:07:58 +0100, Vetle Roeim <>
    > : 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
    Steve (another one), Mar 4, 2004
    #10
  11. On Wed, 03 Mar 2004 17:08:21 +0100, Vetle Roeim wrote:

    > * 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 :)

    --
    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
    James Willmore, Mar 4, 2004
    #11
  12. James Willmore wrote:
    > On Wed, 03 Mar 2004 17:08:21 +0100, Vetle Roeim wrote:
    >
    >
    >>* 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.
    Steve (another one), Mar 4, 2004
    #12
  13. On Thu, 04 Mar 2004 15:51:37 +0000, Steve (another one) wrote:

    > 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>
    James Willmore, Mar 4, 2004
    #13
  14. Thomas Deschepper

    Vetle Roeim Guest

    * Greg Klinedinst
    > On Wed, 03 Mar 2004 21:07:58 +0100, Vetle Roeim <>
    > 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.


    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.


    [...]
    --
    #!/usr/bin/vr
    Vetle Roeim, Mar 4, 2004
    #14
  15. Thomas Deschepper

    Ben Morrow Guest

    Vetle Roeim <> wrote:
    >
    > 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

    --
    Razors pain you / Rivers are damp
    Acids stain you / And drugs cause cramp. [Dorothy Parker]
    Guns aren't lawful / Nooses give
    Gas smells awful / You might as well live.
    Ben Morrow, Mar 4, 2004
    #15
  16. Thomas Deschepper

    Vetle Roeim Guest

    * 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 :)


    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.


    [...]

    --
    #!/usr/bin/vr
    Vetle Roeim, Mar 4, 2004
    #16
  17. On Thu, 4 Mar 2004, Vetle Roeim wrote:

    > 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
    Alan J. Flavell, Mar 4, 2004
    #17
  18. On Thu, 4 Mar 2004, Ben Morrow wrote:

    > 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...
    Alan J. Flavell, Mar 4, 2004
    #18
  19. On Thu, 4 Mar 2004, Alan J. Flavell wrote:

    On Thu, 4 Mar 2004, Vetle Roeim wrote:
    [...]
    > > and those who don't know what they're doing

    >
    > 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.)
    Alan J. Flavell, Mar 4, 2004
    #19
  20. Thomas Deschepper

    Guest

    Scott Bryce <> wrote:
    >
    > 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

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , Mar 4, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dpackwood
    Replies:
    3
    Views:
    1,773
  2. Ken Cox [Microsoft MVP]

    Re: Relationship between IIS Sessions and ASP.NET Sessions?

    Ken Cox [Microsoft MVP], Aug 8, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    5,348
    Luther Miller
    Aug 8, 2003
  3. scottymo
    Replies:
    3
    Views:
    684
    Dominick Baier
    Sep 30, 2006
  4. Bookham Measures

    Moving from ASP Sessions to Database Sessions

    Bookham Measures, Jul 23, 2007, in forum: ASP General
    Replies:
    19
    Views:
    545
    Bookham Measures
    Aug 23, 2007
  5. Wanna-Be Sys Admin

    Perl to use and create PHP sessions?

    Wanna-Be Sys Admin, Nov 19, 2009, in forum: Perl Misc
    Replies:
    5
    Views:
    203
    Wanna-Be Sys Admin
    Nov 20, 2009
Loading...

Share This Page