Re: Passing a username/password from HTML to a Perl script

I have an HTML page there (a product order page) with a form which calls a perl script once the customer has entered all their details in. The perl script needs to create a file in the /data folder and write out some of the information being entered (credit card #, etc).

<Freddo411>: Shudders at the thought of buying things online ;-!

There are many things to worry about when designing and coding web apps for security. Here are a few:

* write the data where the web server cannot see it. This is often done by: a) using a DB on another physical machine b) using a part of the filesystem that NOT visable to the web server (chroot and not under the web root)

Keep in mind that your cgi process must have permission to write/read the file, that means that every CGI on your machine has permission to write/read the file ... IF you store the information unencrypted.

* Encrypt the info. Use your CGI to encrypt the info. Encryption isn't hard to do, but isn't a panacia either. Encryption is based upon using a key and an algorythm to scramble the data. Usually one uses a well known and tested algorythm (see cpan). But the encrypted data is only as safe as the key. Where do keep the key that the CGI must use? If you keep it on the filesystem in a place that the CGI can read it, then it is "open", potentially, for any CGI (or hacked CGI) on the system to read. Really well funded operations use a Hardware Encryption device that securely stores the key, and provides a software interface for encrypting data.

Based upon what you've said so far, the best you can do is to keep the CGI code (except a stub), the encrypted data, and the key file outside the web root using chroot. Make sure that the user that the web server is running as has permission to read (but not write) the key file and the CGI code files. Make sure that no one else can read/write/execute the files or the directories they are in.

Note that this level of security breaks down if the web server is compromised, or if root user is compromised, or if another CGI on the box is compromised.

Good Luck.

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday

Comment on Re: Passing a username/password from HTML to a Perl script

Replies are listed 'Best First'.
Re: Re: Passing a username/password from HTML to a Perl script by Fletch (Bishop) on Feb 04, 2004 at 22:19 UTC
Encryption isn't hard to do ... . . . but it is often difficult to do it right. See Schneier, Secrets and Lies: Digital security in a networked world (ISBN ISBN 0471453803 ).	[reply]
Re: Passing a username/password from HTML to a Perl script by jonadab (Parson) on Feb 05, 2004 at 11:58 UTC
<Freddo411>: Shudders at the thought of buying things online /me generally sends a check. Credit cards are risky IRL just as much as online. Every place where you use a credit card, there is the potential for an unscrupulous employee to jot down, memorize, or otherwise keep your number and use it a year later after they've changed jobs twice and you've used your card in dozens of other places. Anything can happen in this scenerio that can happen if your number is stolen online. You can choose not to worry about either scenerio, figuring either that A) it won't happen to you or B) the credit card company will believe it wasn't you and eat the cost or C) God has everything under control and will protect you from any problems that are not his will, but these things are just as true if you use the card online as they are if you use it IRL. (The real reason I send a check though is because I refuse to own a credit card, because they make it too %$@! convenient to spend money all the time. One can nickle and dime oneself into the poor house.) The thing that's risky about buying online is that if the website is bogus you may not get your merchandise. As yet, I've only had that happen four times, and in each case I was able to get it straightened out (which implies that the site was not, in fact, bogus, merely less than altogether on the ball) and either got the merchandise shipped or got a refund. (Twice I got a refund, and twice the merchandise shipped. Only one of the four cases was a real hassle.) Maybe I've been fortunate in that regard. But yes, the OP really ought to do something more robust with the credit card numbers than store them in a data/ directory. If nothing else, it's very embarrassing for a business to have to announce to all of its customers that their credit card numbers have been stolen. For a small business, that can just totally ruin your public image. `$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/` [download]	[reply] [d/l]
Re: Re: Passing a username/password from HTML to a Perl script by freddo411 (Chaplain) on Feb 06, 2004 at 18:52 UTC
I take your point that credit card numbers can be compromised off-line as well as online. What's different about online credit card crime? A number of things: a) volume, steal 100 or 10K numbers in a single swoop. Drop a latte-sized randomized charge on each one. b) Inclusion of additional info. When I use plastic in a cafe, I don't give them my address/phone/email. Often this is included in an online transaction. Just so we all don't panic and chop up on the plastic right now, keep in mind that you can disavow any charges you did not make, or that have not be satisfactorially fulfilled. It is the responsibility of the vendor to prove that you did make the charge and that the service has been fulfilled. Until then, you don't pay. This can come in handy when you are not satisfied with the goods ( and yes this is a legal and ethical use of this feature of plastic). ------------------------------------- Nothing is too wonderful to be true -- Michael Faraday	[reply]
Re: Re: Passing a username/password from HTML to a Perl script by pelagic (Priest) on Feb 05, 2004 at 13:06 UTC
> Note that this level of security breaks down if the web > server is compromised, or if root user is compromised, > or if another CGI on the box is compromised. If root user is compromised, what's left there not breaking down? pelagic	[reply]