in reply to Passing a username/password from HTML to a Perl script

Abigail and Scottj are right. Don't even consider credit card transactions unless you have SSL, and if you don't have enough saavy to setup a local test server, to test your methods, wait until you do.

In the meantime, you could do something like make a store on your site, but have the payments handled by a third party, which will credit you the amount. That takes the worry off of you, because you never see the cc info. Ebay Sellers work that way. I can't comment on Ebay's Security, but at least it won't be you getting sued. Ebay sellers can have a "homepage store" in addition to what is offered on Ebay, and Ebay will handle the sales for you through their PayPal operation. If you don't like Paypal, there are other similar operations...search for them and compare the rates they charge for handling your cc transactions.

  • 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 mwhiting (Beadle) on Feb 05, 2004 at 20:15 UTC
    Hi - thanks for the answers. I am using an SSL server, the original website is on a 'regular' (?) server, and there is also some space I'm using on their SSL server. This is the 'secure' area I was referring to. I've now got the script to create a file (didn't actually realize Perl would be able to just do it anyway, regardless of anything in .htaccess) the way I want it to. This directory with CC information is not quite an online transaction thing like in bigger companies. The script sends an email to the office staff that there is data to download, so they ftp to the /data directory and copy the file to their own PC. Then they delete the file after they are done. Also the script will look for older files and delete them itself, so there's nothing irrelevant hanging around to cause a problem. It's much more low volume, low tech than what you may have been thinking. The fact that the file & it's contents is physically removed from the server within a short timeframe was my suggestion to the boss. Having nothing there most of the time seemed like the best security to me. I just need to be relatively secure for a short time period. Freddo411 (if I may call you that :) ), you mentioned "keep the CGI code (except a stub) ... outside of the webroot" What did you mean by 'except a stub'? Just a short cgi script to launch the main one, or what? Thanks muchly everyone! Michael p.s. - how do you guys get the carriage returns to stay in your messages? mine are all getting stripped out, which the site says they will be ... but yours aren't?
[reply]
      I'm not a security expert, but have been around long enough to know what the problems are.

      First, if your office staff are going to ftp the file, is the file going to be encrypted? Is it going to use ftp-ssl? If not, the cc info can be captured during the transfer. There are some things you are just becoming aware of....

      1. It's not just data on the computer which puts you at risk, its also the transfer of the data...search for network snoopers and you will have your eyes opened.

      2. Saying "the data is only going to be there a short time" is a problem. Computer time is measured in milliseconds, and scripts can be written to grab things just that quickly.

      3. Keep everything encrypted all the time, and even then you will have to worry about savvy sysadmins who will scrape data off of the memory, where you are using it unencrypted.

      Anyways, as you can see, there is very little you can do to ensure security on a remote server. If you really need to be sure, get your own private server setup at your place of business, and keep it locked in a secure room, under a camera. If you can't afford to that, then keep everything encrypted all the way from the user-submit-form to your office staff ftp download. There are still holes in that method, but they can all point to the remote server sysadmin, who you have to trust. still holes in that method

[reply]

      -------------------------------------
      I tend to use CGI::Application to write my stuff. Under the doc root, the CGIs look like this: 

      #!/usr/local/bin/perl
 use lib "/Application_Perl_Modules";
 use History;
 my $webapp = History->new();
 $webapp->run();

      [download]

      where "History" is in a file History.pm in the directory /Application_Perl_Modules well outside of the docroot. This makes it impossible for the webserver to display the guts of the CGI source code if the .htaccess controls on the CGI directory fail (for example). You can use this trick without using CGI::Application too. Also note this structure allows you to "reuse" code by having many stubs point to the same module, providing an advantage in code maintenence.

      Changing subjects, to answer your other question, paragraph breaks are provided by using standard HTML tags. Read the help ....

      Welcome to the monastery. IMHO most useful site on the internet.

      Cheers

      Nothing is too wonderful to be true
      -- Michael Faraday
[reply]
[d/l]

In Section Seekers of Perl Wisdom