Re: Implementing security in CGI

[Differentiated Software Solutions Pvt. Ltd.]

Hi,

After reading Jeff, Gunther and Manfred, I think I've got a hang of what's
to be done. Thanks for the same.

I just can't help but continue discussion to slightly more
theoritical/hypothetical ways. I would like to understand consequences of
what we're doing.
My questions are
a) If a user enters into the system and views a few pages and gets out of
the system by killing the browser (and not clicking logout) and leaves his
desk with the PC on. A guy who is standing by, on the side, immediately
takes over and launches the browser, picks up one of the inner URLs and that
too before the cron is able to clean up all the sessions, then do we have a
security hole? Is not the user assuming that by killing the browser we are
exiting the system !!
b) Does all this mean that functionally, Apache::Session is a random number
generator with ability to store data and retrieve data associated with these
random numbers. Is this all that it does ??
c) Most importantly for our application, We've written all the programs in
perl/CGI (not mod_perl). I've now realised my folly in not starting off with
mod_perl.... but the deed is done. Can I use Apache::Session or any of these
modules under plain vanilla CGI. Will this work ??

Thanks for the inputs. They have been invaluable.

Murali


-----Original Message-----
From: Gunther Birznieks <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: 20 April 2000 18:19
Subject: Re: Implementing security in CGI


>At 09:53 AM 4/20/00 +0530, Differentiated Software Solutions Pvt. Ltd.
wrote:
>>Hi,
>>
>>Persitent cookies was the dilemna I was in.
>>
>>I also found that there are persistent and non-persistent cookies. I wrote
>>some test Javascript programs and found out that we can have cookies which
>>die after the browser exits. Would this be a good option.
>>Another nagging doubt. Is this the way the world implements security with
>>CGI or am I missing something ??
>The idea that the cookie actually dies with an exiting browser is not
>guaranteed. If you are relying on the client-side for your security, this
>can be spoofed. I could write an HTTP client the conceivably keeps the
>cookie alive and persistent and ignores the expiry info the server sends
>with the cookie.
>
>You should be expiring the sessions themselves through a cron job or some
>dynamic checking mechanism anyway.
>
>There are many ways to do CGI security. They all have their ups and downs.
>Cookies with expiring sessions is one way. Digital Client certificates is
>another.... Normal username/password Basic auth is another ...
>
>Really depends on what you want to do and what tradeoffs you want.
>
>Later,
>   Gunther
>
>>Thanks a lot for informing me about this news group. I'll keep tabs on
this
>>group.
>>
>>Murali
>>-----Original Message-----
>>From: Jeff Beard <[EMAIL PROTECTED]>
>>To: Differentiated Software Solutions Pvt. Ltd. <[EMAIL PROTECTED]>;
>>[EMAIL PROTECTED] <[EMAIL PROTECTED]>
>>Date: 20 April 2000 10:55
>>Subject: Re: Implementing security in CGI
>>
>>
>> >This is a question for comp.infosystems.www.authoring.cgi.
>> >
>> >But since I'm here...
>> >
>> >I would check for the cookie every time a request is made. If you use
>> >Apache::Session there will be a separate session data store from the
user
>> >data. Which is probably what you really want. Apache::Session will allow
>> >you to associate whatever data you like with the session id within it's
own
>> >schema.
>> >
>> >If the browser is closed, the cookie will remain. You can have a logout
>> >feature but there will always be a significant percentage of users that
>> >won't bother. So limit the life of the cookie with the time value and
>> >periodically cull stale sessions on the server.
>> >
>> >--Jeff
>> >
>> >
>> >At 05:21 PM 4/19/00, Differentiated Software Solutions Pvt. Ltd. wrote:
>> >>Hi,
>> >>
>> >>My question is much more basic than that. I wanted to validate my
design
>> >>ideas on a programmatic security.
>> >>I would like somebody to go through the following and tell me that I'm
on
>> >>the right track.
>> >>
>> >>The idea I had was, at the time of login, I generate the session id
which
>>I
>> >>write to the cookie.
>> >>I have also tied to this session_id the user's login profile.
>> >>Every other screen checks for the cookie's existence and reads back the
>> >>session_id and gets the user's profile. I hope I'm right till then.
>> >>When the user signs out then we can delete the tied file.
>> >>Now any person who has access to the same browser will still have to
login
>> >>to get to the inner pages.
>> >>
>> >>If the browser is killed without sign-out from the system, even then
>>there's
>> >>no problem.
>> >>Next person who gets access to the browser and tries to access any
inner
>> >>page will not be able to, because the cookie with the session-id does
not
>> >>exist.
>> >>
>> >>Am I right ??? Please help.
>> >>
>> >>Thanks,
>> >>
>> >>Murali
>> >>
>> >>-----Original Message-----
>> >>From: Gunther Birznieks <[EMAIL PROTECTED]>
>> >>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> >>Date: 19 April 2000 18:44
>> >>Subject: Re: Implementing security in CGI
>> >>
>> >>
>> >> >Apache::Session could be useful. But the session key that is
generated
>>is
>> >> >arguable not necessarily the most secure that it could be. But it is
>>pretty
>> >> >good.
>> >> >
>> >> >I'm probably opening up a can of worms by saying this.
>> >> >
>> >> >The MD5 hash itself is relatively secure as hashes go (although SHA
hash
>> >> >space could be better). But you are relying on underlying system
>>variables
>> >> >to determine what is put into MD5 hashing in the first place -- and
this
>> >> >data is not necessarily the most random-- process ID, time, memory
>>address
>> >> >of the created hash, etc... Are a bit deterministic. rand() might be
>>good
>> >> >if it is on a system that plugs natively into a good entropy
generator
>>on
>> >> >that machine.
>> >> >
>> >> >To get a better key, you probably end up spending more time pulling
>> >> >relatively random data sources together so key generation itself
would
>>be
>> >> >slow-- a computational tradeoff. Depends on how "secure" you really
want
>>to
>> >> >be. For most situations,  Apache::Session's key generator will work
>>fine.
>> >> >
>> >> >It also depends how long you intend the sessions to be active. Will
they
>> >> >become a "token" that is used in lieu of authentication once the user
>>has
>> >> >entered a username and password or issued a digital client
certificate
>>to
>> >> >your web site? Or will it be used after the user registers for a
month+
>>to
>> >> >allow them to get back into your site without remember a password.
>> >> >
>> >> >-- Gunther
>> >> >
>> >> >At 01:34 PM 4/19/00 +0530, Differentiated Software Solutions Pvt.
Ltd.
>> >>wrote:
>> >> >>Hi,
>> >> >>
>> >> >>We are having a site which is programmed with perl/CGI.
>> >> >>To enter the site we have a login and password.
>> >> >>After which some reports are displayed.
>> >> >>
>> >> >>I know that using cookies it is possible to secure the site.
>> >> >>Can somebody guide me on how to design and implement a cookie based
>> >> >>security. Sites and books on same will be greatly appreciated.
>> >> >>
>> >> >>Would Apache::Session be useful for this ??
>> >> >>
>> >> >>Thanks for the help,
>> >> >>
>> >> >>Murali
>> >> >>
>> >> >>Differentiated Software Solutions Pvt. Ltd.,
>> >> >>176, Gr. Floor, 6th Main
>> >> >>2nd Block RT Nagar
>> >> >>Bangalore - 560 032
>> >> >>India
>> >> >>Ph: 91 80 3431470
>> >> >>email : diffs+AEA-vsnl.com
>> >> >>http://www.diffs-india.com
>> >> >>
>> >> >>Differentiated Software Solutions Pvt. Ltd.,
>> >> >>176, Gr. Floor, 6th Main
>> >> >>2nd Block RT Nagar
>> >> >>Bangalore - 560 032
>> >> >>India
>> >> >>Ph: 91 80 3431470
>> >> >>email : diffs+AEA-vsnl.com
>> >> >>http://www.diffs-india.com
>> >> >
>> >> >__________________________________________________
>> >> >Gunther Birznieks ([EMAIL PROTECTED])
>> >> >Extropia - The Web Technology Company
>> >> >http://www.extropia.com/
>> >
>> >
>> >
>> >Jeff Beard
>> >_______________________________
>> >Web: www.cyberxape.com
>> >Phone: 303.443.9339
>> >Location: Boulder, CO, USA
>> >
>
>__________________________________________________
>Gunther Birznieks ([EMAIL PROTECTED])
>Extropia - The Web Technology Company
>http://www.extropia.com/