Cookie Security
My client has had me implement some very proprietary algorithms. He wants to charge his clients money every time someone requests these calculations be preformed on their very sensitive. In addition my client anticipates storing this extremely sensitive data using Microsoft Access on his site which is largely implemented in Perl CGI. Are there any special considerations with regard to Perl when we start incorporating SSL? My understanding is that SSL/https is completely transparent: our only change is that our URLs will contain https instead of http - correct? Since all our data will be sensitive, we will not only be using Perl to keep passwords safe, but everything we transmit and receive. Now what about incorporating a certificate server like Verisign? I think this is completely transparent too. We want Verisign to prevent an imposter from creating a web site that looks identical to ours. I believe there are no changes to our Perl CGI code for this either. Finally, what about using cookies for authentication and authorization? Assuming his clients are amenable to turning cookies on, I believe the favorite algorithm is to generate a random number when we prompt for a password and (assuming the user enters a valid username and password) store this number both in the cookie on the browser and in the database. The browser always presents this number to the Perl CGI code and we look up the number in the database to find the username and bump a counter in our database everytime the user requests an evaluation. Is this approach secure? I am suspicious because in the Microsoft .NET literature they suggest that cookie (or forms) security is only medium security appropriate for storing things like frequent flyer miles or email and is not appropriate for credit cards. What would be a more secure approach to authentication and authorization? Thanks, Siegfried
unable to overwrite a parameter in the session
Hi,
I'm writing a cgi application that exploits cgi::session, but it seems as I'm
unable to overwrite some parameters. Consider the following code:
sub clearSession{
# get local parameters
my ($_cgi_, @_toDelete_) = @_;
my ($_sessionID,$_session,$_username_,$_config_,$_permissions_,
$_original_root_);
my ($_page_,$_current_page_,$_tmp_);
# get the current session
my $_sessionID = $_cgi_-cookie('CGISESSID') || $_cgi_-param('CGISESSID')
|| undef();
my $_session = new CGI::Session( undef(), $_sessionID, {Directory =
'/tmp'} );
$_page_ = $_session-param($_PAGE_KEY_);
$_current_page_ = $_cgi_-url(-relative=1);
# is the user on the same page?
if( $_page_ ne $_current_page_ || ! $_page_){
# the page has changed
$_username_ = $_session-param($_USERNAME_KEY_);
$_config_ = $_session-param($_CONFIG_KEY_);
$_config_ = $_session-param($_CONFIG_KEY_);
$_permissions_= $_session-param($_PERMISSIONS_KEY_);
$_original_root_ = $_session-param($_ORIGINAL_ROOT_KEY_);
print FILE \nentrato!\n;
$_session-clear();
$_session-param(-name = $_USERNAME_KEY_,-value =
$_username_);
$_session-param(-name = $_CONFIG_KEY_, -value =
$_config_);
$_session-param(-name = $_PERMISSIONS_KEY_, -value =
$_permissions_);
$_session-param(-name = $_ORIGINAL_ROOT_KEY_, -value =
$_original_root_);
$_session-param(-name = $_PAGE_KEY_,-value =
$_current_page_);
$_session-flush();
}
elsif( not $_page_ ){
# the page is not yet defined
$_page_ = $_current_page_;
$_session-param(-name = $_PAGE_KEY_,-value = $_current_page_);
}
}
I'd like to call this function on each page of my program, in order to clean
the session from dirty data when the user changes the page. However, even if
I'm able to write and change a few parameters, and I'm sure that the
subroutine does the first if, the $_PAGE_KEY_ variable is never changed from
its initial value. I'm sure $_current_page changes, because I print the same
value on the page, thus I can see it changing, but the value in the session
never changes.
Any idea?
Thanks,
Luca
--
Luca Ferrari,
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: Cookie Security
On Tue, Aug 31, 2004 at 08:30:35AM -0600, Siegfried Heintze wrote: My client has had me implement some very proprietary algorithms. He wants to charge his clients money every time someone requests these calculations be preformed on their very sensitive. In addition my client anticipates storing this extremely sensitive data using Microsoft Access on his site which is largely implemented in Perl CGI. Microsoft Access does not scale. Consider using SQL Server if it must be MS, or investigate the open source databases like PostgreSQL and MySQL if cost is an issue. Stray away from using Access for anything production as its meant to be a simple DB. It will burn them. Most of my current job is converting all the Access DB's floating around to our Oracle DB, while the MIS department is figuring out ways to make sure Access will not run on anyone's computers :) Are there any special considerations with regard to Perl when we start incorporating SSL? My understanding is that SSL/https is completely transparent: our only change is that our URLs will contain https instead of http - correct? Since all our data will be sensitive, we will not only be using Perl to keep passwords safe, but everything we transmit and receive. SSL provides a wrapper around your packets ensuring their encrypted. Now what about incorporating a certificate server like Verisign? I think this is completely transparent too. We want Verisign to prevent an imposter from creating a web site that looks identical to ours. I believe there are no changes to our Perl CGI code for this either. You are correct, CA and Certificates are a part of the SSL suite and handled without any provisions in your code. By the time your code executes, this is completely setup. Finally, what about using cookies for authentication and authorization? Assuming his clients are amenable to turning cookies on, I believe the favorite algorithm is to generate a random number when we prompt for a password and (assuming the user enters a valid username and password) store this number both in the cookie on the browser and in the database. The browser always presents this number to the Perl CGI code and we look up the number in the database to find the username and bump a counter in our database everytime the user requests an evaluation. More than just a random number in most cases. Usually double md5sum of the epoch bitwise or'd or appended with the process id number, ip address, or user id or a combination of thereof might work. Is this approach secure? I am suspicious because in the Microsoft .NET literature they suggest that cookie (or forms) security is only medium security appropriate for storing things like frequent flyer miles or email and is not appropriate for credit cards. What would be a more secure approach to authentication and authorization? I believe they mean don't store the credit card information in the cookie. Storing some sort of decent hash of some data that identifies a user on your site is pretty good. Cookies are stored on the client's machine and kept in a place where the browser can send them a malicious site if there exists a bug in the browser. So yeah, don't store social security numbers or credit card numbers in the cookie, but some sort of identifier is fine. In theory, the attacker could take control of the host machine, use that cookie to log in and then extract the credit card information through your interface, but at that point, there's not much you could do anyways. Thanks, Siegfried -- Brad Lhotsky [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
RE: Cookie Security
Please see my questions in line! Thanks! In addition my client anticipates storing this extremely sensitive data using Microsoft Access on his site which is largely implemented in Perl CGI. Microsoft Access does not scale. Consider using SQL Server if it must be MS, or investigate the open source databases like PostgreSQL and MySQL if cost is an issue. Stray away from using Access for anything production as its meant to be a simple DB. It will burn them. Most of my current job is converting all the Access DB's floating around to our Oracle DB, while the MIS department is figuring out ways to make sure Access will not run on anyone's computers :) I have explained the performance problems with Microsoft Access many times to my customer and he does not listen. (This is because it is not a problem with only he and I prototyping the site). What you describe is a performance issue, not a security issue. It sounds like MSAccess is just as secure as those other databases, correct? Finally, what about using cookies for authentication and authorization? Assuming his clients are amenable to turning cookies on, I believe the favorite algorithm is to generate a random number when we prompt for a password and (assuming the user enters a valid username and password) store this number both in the cookie on the browser and in the database. The browser always presents this number to the Perl CGI code and we look up the number in the database to find the username and bump a counter in our database everytime the user requests an evaluation. More than just a random number in most cases. Usually double md5sum of the epoch bitwise or'd or appended with the process id number, ip address, or user id or a combination of thereof might work. Do you have a reference where I could read up on this? Thanks, Siegfried -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Cookie Security
On Tue, Aug 31, 2004 at 08:30:35AM -0600, Siegfried Heintze wrote: My client has had me implement some very proprietary algorithms. He wants to charge his clients money every time someone requests these calculations be preformed on their very sensitive. In addition my client anticipates storing this extremely sensitive data using Microsoft Access on his site which is largely implemented in Perl CGI. Microsoft Access does not scale. Consider using SQL Server if it must be MS, or investigate the open source databases like PostgreSQL and MySQL if cost is an issue. Stray away from using Access for anything production as its meant to be a simple DB. It will burn them. Most of my current job is converting all the Access DB's floating around to our Oracle DB, while the MIS department is figuring out ways to make sure Access will not run on anyone's computers :) I second this, *please* use something other than Access. snip Finally, what about using cookies for authentication and authorization? Assuming his clients are amenable to turning cookies on, I believe the favorite algorithm is to generate a random number when we prompt for a password and (assuming the user enters a valid username and password) store this number both in the cookie on the browser and in the database. The browser always presents this number to the Perl CGI code and we look up the number in the database to find the username and bump a counter in our database everytime the user requests an evaluation. More than just a random number in most cases. Usually double md5sum of the epoch bitwise or'd or appended with the process id number, ip address, or user id or a combination of thereof might work. I don't understand how you are using this info? The process id number would change between requests, as might the IP address (think proxies). I wrote up a fairly common idiom in a previous message to this list, it goes like such: Generally the idiom goes something like, create a private key (aka a passphrase or something that no one else knows), take the key and some reproducible non-private information (such as the user name/id) and hash the two together. Provide the hash, and the information used to create it (NOT the private key!) in the cookie. Then during the requests check to see if the information provided back by the user from the cookie can be used to reproduce the same hash using the same private key as before. If the hash is reproduced then the user is authenticated. Assuming no one else has the private key, then the hash should be unique for the user and the private key should be non-guessable from the hash, generally if this holds an attacker can't produce a string that will authenticate correctly. In general using the IP address in this is not a good idea unless you know precisely what IP a particular user is going to come from. The complexity of your hash inputs can vary what you can do, aka adding expirations, etc. I don't take credit for this, the idiom is yanked from the Writing Apache Modules with Perl and C book from ORA, it provides an excellent discussion as well as code samples of how to implement this. Also not sure about the double MD5, are you positive that doesn't introduce a vulnerability, by MD5ing a hash you seemingly have reduced its power since it is a hash of a relatively short string which could definitely be brute forced very quickly? I would skip MD5 completely and go with SHA-1 (although there are recent concerns about it), and would definitely double check hashing a hash with an encryption expert before doing it. Is this approach secure? I am suspicious because in the Microsoft .NET literature they suggest that cookie (or forms) security is only medium security appropriate for storing things like frequent flyer miles or email and is not appropriate for credit cards. What would be a more secure approach to authentication and authorization? I believe they mean don't store the credit card information in the cookie. Storing some sort of decent hash of some data that identifies a user on your site is pretty good. Cookies are stored on the client's machine and kept in a place where the browser can send them a malicious site if there exists a bug in the browser. So yeah, don't store social security numbers or credit card numbers in the cookie, but some sort of identifier is fine. In theory, the attacker could take control of the host machine, use that cookie to log in and then extract the credit card information through your interface, but at that point, there's not much you could do anyways. Agreed. Thanks, Siegfried -- Brad Lhotsky [EMAIL PROTECTED] http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Cookie Security
On Tue, Aug 31, 2004 at 09:31:52AM -0600, Siegfried Heintze wrote: I have explained the performance problems with Microsoft Access many times to my customer and he does not listen. (This is because it is not a problem with only he and I prototyping the site). What you describe is a performance issue, not a security issue. It sounds like MSAccess is just as secure as those other databases, correct? Or just as insecure depending on how you are passing data to it. At any rate, I agree with you that it's a performance issue, not a security issue. More than just a random number in most cases. Usually double md5sum of the epoch bitwise or'd or appended with the process id number, ip address, or user id or a combination of thereof might work. Do you have a reference where I could read up on this? Check out the Authen::* modules on CPAN as well as CGI::Auth and CGI::Session. Good luck, William -- Knowmad Services Inc. http://www.knowmad.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
RE: Cookie Security
On Tue, 31 Aug 2004, Siegfried Heintze wrote: I have explained the performance problems with Microsoft Access many times to my customer and he does not listen. (This is because it is not a problem with only he and I prototyping the site). What you describe is a performance issue, not a security issue. It sounds like MSAccess is just as secure as those other databases, correct? Access is not a multi-user, server-oriented database. This makes it fundamentally distinct from MySQL, PostgreSQL, Oracle, SQL Server, etc, and the usual concepts of security with those databases are hard to apply. Access is a single-user, desktop database, like FileMaker Pro or Phoenix (the open source database that almost no one has heard of or uses, not the open source web browser (which is now known as Firefox), which lots of people know of and use). This, to me, implies that any internet facing use of Access (or a similar desktop database) is an inappropriate kludge that should not be used for anything meant to be taken seriously. From what I've heard, Microsoft makes it very easy for people to upgrade databases from Access to SQL Server; you should please consider this. -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/blog/ np: 'Fraggle Rock Theme Song (lo-fi midi version)' by Fraggles from 'Fraggle Rock' -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
RE: Cookie Security
At 12:43 PM 8/31/2004, you wrote: Access is a single-user, desktop database, like FileMaker Pro or Phoenix (the open source database that almost no one has heard of or uses, not the open source web browser (which is now known as Firefox), which lots of people know of and use). This statement has some potential for being a very great mis-characterization of a great client-server database: Firebird. The confusion perhaps arises because at one time Firefox (the browser) was being called Firebird. Since the Firebird database server (open-source enhancement of the Borland InterBase d/b) already was using the name, the browser folks backed down and changed the browser to Firefox. The term Phoenix might have come into play here because one of the major [commercial, but very generous] supporters of the Firebird RDBMS is IBPhoenix and the logo for Firebird is a phoenix. The Firebird support list is one of the most active you will ever see. But Firebird, the database system, is a magnificent, fully SQL-standard compliant, rock-solid system capable of handling millions of records and hundreds of simultaneous users. APress has just published a 1000-page book on it: The Firebird Book by Helen Borrie. ISBN 1-59059-279-4. I have no connection with Firebird, other than having successfully deployed applications using it. If there is another desktop database called Phoenix (of which of course I have not heard), then this is all immaterial. Dennis McFall -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Need help on Chinese registration form
I am working on the Chinese registration form, first time I do that, but have a lot of questions. 1) The user will type in Chinese character, simple, on my form but how will I know if I am capturing the Chinese character correctly so that I can save to a flat file. 2) The submitted data will be saved to a tab delimited flat file. We will just open the flat with excel to view the data. The question is how can I save the data to the flat file so that I can view the Chinese character in excel? I tried to copy and paste some Chinese character in note pad then open with excel. It works if I save the file in Unicode format. 3) My perl cgi script will display some Chinese message interactively. I have a lot of problem when I tried to embed Chinese character with my code. Please help. Daniel
