Thread: Re: [htmltmpl] Perl CGI authentication and session management
Brought to you by:
samtregar
From: <Seb...@3S...> - 2003-10-15 07:10:29
|
Hi David. Most session tracking software use the same approach: 1.) Establish an SSL connection 2.) Require the user to indentify himself (username and password) 3.) Check against some kind of user database 4.) Create a unique session ID number which can not easily guessed by others 5.) Store the ID on the users machine (cookie) or send it as part of the HTTP request ("foo.bar.org/myscript?SID=3Da3cc69...") The biggest security issue is the session ID itself. If you write your application carefully no other session data will ever leave your server. Cookies are a bit more insecure because they are stored on the client machine in uncrypted format. If someone gets a copy of the ID (and the session has not exipred yet) then he or she might be able to intercept the connection. Most session mechanisms use some kind of IP address matching to ensure each session ID is used from only one machine but this has to be considered as a weak obstacle for crackers since IP addresses may be spoofed easily. Of course this is mainly a client side issue but one your users should be aware of. If you choose the cookie approach then make sure the cookie expires when the browser is closed. I use CGI:Session in combination with HTML::Template and they cooperate well. Nicest feature is that you can redisplay pages filled with session data with a few lines of code (e.g. if you want a user to correct input made earlier in the session). Regards, Sebastian > hello, world! >=20 > I'm working on an e-commerce site using Apache 1.3.26, Perl 5.6, > CGI::Application, HTML::Template, and CGI::FormBuilder. I need to > provide secure user login/logout, profiles, financial pages,=20 > etc.. For > starters, I plan to use https for sensitive pages. After=20 > that, I'm not > sure which way to go. I would prefer using a standard CPAN=20 > module, such > as CGI::Session and/or CGI::Session::Auth. >=20 >=20 > What experiences, recommendations, comments, criticisms, and/or > suggestions do the list readers have in the areas of user=20 > authentication > and session management using Perl and CGI? Does anyone have URL's for > some good articles, tutorials, etc.? >=20 >=20 > TIA, >=20 > David |
From: David C. <dpc...@ho...> - 2003-10-15 07:50:11
|
htm...@li...: Bär, Sebastian wrote: > Most session tracking software use the same approach: Thanks for the reply. :-) > 1.) Establish an SSL connection > 2.) Require the user to indentify himself (username and password) > 3.) Check against some kind of user database > 4.) Create a unique session ID number which can not easily guessed > by others > 5.) Store the ID on the users machine (cookie) or send it as part > of the HTTP request ("foo.bar.org/myscript?SID=a3cc69...") As I thought. Question: are the HTTP requests (with CGI fields and values, including session_id) encrypted when using https? > The biggest security issue is the session ID itself. If you write > your application carefully no other session data will ever leave > your server. I should be able to do that. > Cookies are a bit more insecure because they are stored on the > client machine in uncrypted format. Okay. > If someone gets a copy of the ID (and the session has not exipred > yet) then he or she might be able to intercept the connection. > Most session mechanisms use some kind of IP address matching to > ensure each session ID is used from only one machine but this > has to be considered as a weak obstacle for crackers since IP > addresses may be spoofed easily. > Of course this is mainly a client side issue but one your users > should be aware of. If you choose the cookie approach then make > sure the cookie expires when the browser is closed. I suspected as much. The only solution I could think of was digital signatures on both the client and the server. > I use CGI:Session in combination with HTML::Template and they > cooperate well. Nicest feature is that you can redisplay pages filled > with session data with a few lines of code (e.g. if you want a user to > correct input made earlier in the session). Good. I've been able to get CGI::Application, HTML::Template, and CGI::FormBuilder working together, but it took careful reading of the documents, a fair amount of thinking, and a bit of experimentation. Thankfully, the various module authors anticipated the other modules and provided hooks. It has been satisfying to see OO code reuse actually work in a real-world application! David |
From: Puneet K. <pk...@ei...> - 2003-10-15 12:26:51
|
On Wednesday, October 15, 2003, at 02:49 AM, David Christensen wrote: > .. > > >> 1.) Establish an SSL connection >> 2.) Require the user to indentify himself (username and password) >> 3.) Check against some kind of user database >> 4.) Create a unique session ID number which can not easily guessed >> by others >> 5.) Store the ID on the users machine (cookie) or send it as part >> of the HTTP request ("foo.bar.org/myscript?SID=a3cc69...") > > As I thought. > > > Question: are the HTTP requests (with CGI fields and values, including > session_id) encrypted when using https? yes. .. > >> I use CGI:Session in combination with HTML::Template and they >> cooperate well. Nicest feature is that you can redisplay pages filled >> with session data with a few lines of code (e.g. if you want a user to >> correct input made earlier in the session). > > Good. I've been able to get CGI::Application, HTML::Template, and > CGI::FormBuilder working together, but it took careful reading of the > documents, a fair amount of thinking, and a bit of experimentation. > .. I just got done creating a framework for a secure application (well, not so secure because I don't use https... more like a "personalized weak security" application). I used CGI-Session. Very nicely done application. I wish CGI-Session had a driver for my favorite dsn, SQLite, but hopefully that will arrive eventually (CGI-Session author provides instructions on creating ones own driver, but such things are beyond me as I am mortal). Most personalized/security applications depend on the "server," and as such, would work better with Apache+mod_perl, but even with plain Apache the mileage is pretty good. |