Security Issues

Merchant OrderForm Web Based Shopping Cart System @ 2001
 All about security issues with MOFcart and the Internet

Table of Contents | FAQ | Installation | Security Issues | Building Input Pages | Formatting
Configurations1 | Configurations2 | About Configurations | Troubleshooting | Customizing

These programs are protected by copyright and may not be resold or distributed. Please see the copyright notice for more information on your end user license for this program.

What about security ?

Security is your responsibility! If doing your own installation, it is your responsibility to insure that you have installed this product in a secure way. Inexperienced CGI installers often leave common, yet fixable, security flaws when installing an application of this type. Do not be one of them.

While the program itself has been carefully thought through to prevent any internal security holes, it is possible to create security holes with a faulty installation.  Faulty installations are by far the most common security holes found when running cgi scripts on a web site.  Faulty installations are responsible for more security holes in cgi scripts than all of the fanfare about SSL encryption.

If doing your own installation, review all the items in this checklist to determine if you have a secure installation.

A security checklist

  1. Configuration files not accessible from a web browser. Very important
  2. Directory contents listing not accessible from a web browser for:
  3. Configuration files not accessible from other server users
  4. Directory content not accessible from other server users for:
  5. MOF security settings (configuration files) are:
  6. ../invoices/ directory password protected from index bots
  7. ../orderinfo/ directory password protected (if inside public web area)
  8. Credit card or checking number scrambling codes enabled
  9. MOF back end running under SSL if credit card number taken on your site


Important: Once you are satisfied that your installation is secure, it is important that all adjustments remain intact.

  • Do not adjust permissions on files in other ways
  • Do not delete "no access" messages if installed
  • Do not delete password protection if installed

Always host with a reputable company. Most commercial servers have good security. It is in their best interest to do so. It is possible for your server administrators to make future changes to their servers which compromise the security measures you set in place during your installation.

 

GENERAL SECURITY NOTES Sections LIst How Do I ?

MOF does not store credit card or checking account numbers on the server.  The only information MOF stores on the server are scratch files that contain a cart's products and the shipping destination.  It can be customized to store any information you want, but unless this is programmed in, then MOF will not store any logs with important information. 

When do you need SSL ?

If you are not using any of MOF's payment methods that collect real credit card numbers or real checking account numbers on the MOF Billing information screen, then you do not necessarily need SSL

 
Which payment methods are enabled in MOF ?
need SSL
don't need SSL
Any credit card method Mail or Fax Payment
Online Checking Draft Call Me For Card Info
On Account PayPal
Full Gateways Partial gateways (like PayPal)
COD Delivery

 

A full gateway is where you collect cc information on the MOF Billing information screen, and then pass to the gateway. A partial gateway is like PayPal, where all cc info is collected on the gateway servers' forms, not MOF's.



IS YOUR CGI-BIN SECURE ? Sections LIst How Do I ?

The most common security hole is running your cgi scripts on a poorly configured web server.  A well configured web server will not allow any outside access to your cgi-bin from the world wide web except to execute specified scripts.  A poorly configured web server's cgi-bin will execute the specified script file if called from your browser, but will also allow any other file in your cgi-bin to be called by the browser.  So, with a poorly configured web server's cgi-bin, anyone on the world wide web could pull up a standard *.txt file, or even the *.conf or *.pl files for MOF and read them in their browser.

This would be a serious security hole if you are using the credit card scrambling codes, or had MySQL database login and passwords in your mofpay.conf. Anyone in the world would be able to read your mofpay.conf file from the web.

If you're not using the credit card mail scrambling codes, or MySQL databases, then it couldn't cause much harm, however, you still don't want MOF's configuration files viewed via the web.

A well configured server's cgi-bin would not allow that.  If you attempted to call up the mofpay.conf from a web browser on a properly configured virtual domain's cgi-bin then you would simply get error messages from the server saying you don't have permission to access that file, etc. A poorly configured cgi-bin would give your the file. Not good.

Poorly configured cgi-bins would also allow a browser to list the contents of the cgi-bin directory.  You don't want anyone listing all the files in that directory.  A properly designed cgi-bin will prohibit a browser from calling up the contents of your cgi-bin directory and all the files living there.


Testing your configuration files:

Type in the full URL to <mof.conf> on your server
Type in the full URL to <mofpay.conf> on your server

http://www.site.com/cgi-bin/mcart/mof.conf
http://www.site.com/cgi-bin/mcart/mofpay.conf

If you can either view or download these files from your browser, you are not secure. If you receive a "forbidden" or "no access" or "permission denied" type message, you are secure

Type in the URL for the cgi-bin directory listing on your server

http://www.site.com/cgi-bin/
http://www.site.com/cgi-bin/mcart/

If you see a list of all the files in your cgi-bin or /mcart/ directory then you are not secure. If you receive a "forbidden" or "no access" or "permission denied" type message, you are secure

Did you pass ?

If your cgi-bin passes these tests, then you have a well configured cgi-bin and it is secure.  We do not mean secure with regard to encryption, but secure in that no one can access files in your cgi-bin they are not allowed to.

Note: you must test all sub directories, as well as the main cgi-bin

If you did not pass ?

Most virtual domain accounts with a reputable hosting service have properly designed cgi-bins.  If you are not on a virtual domain, but running out of a subordinate domain set up, then you run into more risk of an improperly configured cgi-bin.  The best solution is to get a virtual domain with a host that has properly configured cgi-bins.

If you don't have a properly configured virtual domain account, or can't afford one, then there are some solutions, but they are not as good as the properly configured cgi-bin.

1.  Place a plain index.htm file in your cgi-bin and all subordinate directories. Give it a message like "no access to this area." If someone attempts to list the contents of your cgi-bin from the world wide web then they will get the no access message.  This strategy prevents a browser from listing the files in your cgi-bin.  It's also a good idea to do with all of your directories on your web site.

This measure only prevents a directory listing.  One could still make a direct call to the exact file they wanted and would be able to get it.  That would be easy to do once someone saw you were running Merchant OrderForm on your site.  Anyone can read the docs and see what the configuration files are.  So they simply ask for that file.

To prevent an exact file listing you can use these solutions:

2. Try to assign CHMOD 711 permissions on both of the MOF configuration files

  • mof.conf
  • mofpay.conf

    Owner    : Read, Write, Execute
    Group: Execute (only)
    Other: Execute (only)

Note: this will not work on all servers. This is the best solution if it works, but if you do this an then get an Internal Server error, then you'll have to return the *.conf file permissions to 755 for MOF to work, and you'll have to rename the *.conf files

3.  Rename both configuration files (*.conf) to complex names that someone will not be able to guess. 

Example:

  • mof.conf ---> ab-9457-v14wex
  • mofpay.conf ---> PAYab-9457-v14wex

It would be pretty hard for someone to make a direct browser request for that file.  But make sure solution number 1 is in place, else they could simply list the contents of your cgi-bin and see your new file name.

Important: If you rename your *.conf files, then you must adjust the main program scripts to require the new names.

In both of the main program scripts,  mof.cgi and mofpay.cgi there are a few lines directly below all the copyright and disclaimer notices.  These settings in each of the two main program files must be changed to match your new file names or MOF will not be able to find the files it needs to run.  The settings you need to adjust look like this:

# DO NOT CHANGE ANY OF THESE SETTINGS
# ===============================

  • mof.cgi
    require 5.001;
    require 'mof.conf'; ---> require 'ab-9457-v14wex';
    require 'moflib.pl';


  • mofpay.cgi
    require 5.001;
    require 'mofpay.conf'; ---> require 'PAYab-9457-v14wex';
    require 'mofpaylib.pl';


4. Place both configuration files in a subordinate .htaccess protected directory. You may want to consider this in addition to suggestion 3 above, especially if you have a loosely configured server. Even though someone can't guess the file names, you don't want scanning bots trying to index those files. Although, if you're down to these kinds of concerns, we strongly recommend you find a hosting service with better security for running CGI scripts.



ARE YOUR DATAFILES SECURE ? Sections LIst How Do I ?

Are these directories outside public web access ?
For more note on creating these directories see: Docs > Installation.html

Try to access the data directories from your web browser. Try to list the file contents from your web browser

Type in the URL for the directory listings on your server

http://www.site.com/orderdata/
http://www.site.com/orderinfo/

If you see a list of all the files then you are not secure. If these directories are in your account root file space, they will not be accessible from the web

if inside public web area

1.  Place a plain index.htm file inside these directories. Give it a message like "no access to this area." If someone attempts to list the contents of these directories from the world wide web then they will get the no access message.  This strategy prevents a browser from listing the files in these directories

2. Protect these directories with .htaccess. It is not sufficient to simply place "No Access" messages in those directories, because indexing bots can index them. While these files do not contain credit card information, they do contain shipping names, addresses, etc. Use the .htaccess files that were placed inside the /orderdata/ and /orderinfo/ directories in the MOF package. You do not need any passwords, you will never need web browser access to these files. Only the scripts need access to these directories.

Important Note to FrontPage users: if you use the .htaccess file in your ../orderdata/ and ../orderinfo/ directories, be extra careful to FTP the .htaccess file *only* to those directories. If you accidentally FTP the .htaccess file to other directories, you will contaminate the FrontPage extensions, losing FrontPage access to your web site.



IS THE INVOICES DIRECTORY SECURE ? Sections LIst How Do I ?

If you use this feature, you'll need precautions to prevent directory listings, and scanning from indexing bots. All 3 precautions should be in place for the /invoices/ directory.

1.  Place a plain index.htm file inside the directory. Give it a message like "no access to this area." If someone attempts to list the contents of this directory from the world wide web then they will get the no access message.  This strategy prevents a browser from listing the files in these directories

2. The MOF template called mofinvoice.html should always include the meta tag to minimize robot scanning and listing in the search engines.  Our packaged template mofinvoice.html has this installed properly.  If you make your own template for this invoices, then make sure you get this meta tag installed correctly, so that those pages, when they are created, will have a No Index, No Follow meta tag to the search engines.

<meta name="robots" content="noindex,nofollow">

3. Take extra measures:

We also strongly recommend that you create password protection for the ../invoices/ directory on the server. This is the only totally safe way to prevent non compliant robots from indexing your invoices directory. It's very easy to do for Unix/Linux servers, and will insure the safety of your customers' invoices.

Htpasswd Password Manager v1.0, Free, available at CGI-Factory.com, will do the job.
http://www.cgi-factory.com/software/

All you need is a general user : password. You don't need to give every customer their own password. One password prevents indexing from bots. We've included a place in the mofpay.conf for you to define user : pswd, which will be printed in the customer mail order confirmation. They will know the user : pswd when MOF mails them.


IS SERVER SECURE FROM TRAVELING ? Sections LIst How Do I ?

If you are on a commercial hosting service, check that your server is secure from other hosting customers traveling to your file space internally.

FTP to your account. Try going up in directory levels.

  1. Can you travel to the root server space ?
  2. Can you see all the other accounts listed ?
  3. If so, go into one of the other accounts.
    Can you see any files listed ?

If your server's FTP server denies permission to do that, then you are secure. If you can travel into the server's upward directories, then you are probably still secure, unless when traveling into another account you are able to see files listings. If you do not see any file listings you are secure.

If you see file listings

Get another hosting company



IS ALLOWED_DOMAINS / POST_ONLY ENABLED ? Sections LIst How Do I ?

These two features should be enabled. If they are disabled, then nothing serious can happen, like viewing your configuration files, but it would allow someone who knew what they were doing to use your cart to submit any products they wanted, with any details. I would not allow them to obtain your mail, or get the order necessarily approved, since all order notices come to the merchant, who can easily review them..

See more about these settings in:


ARE CREDIT CARD CODES ENABLED ? Sections LIst How Do I ?

The current distribution package does not have a plug in for sending mail via an encryption scheme like PGP.  What we have provided is a simple scrambling method where the first set of four numbers and/or the second set of four number of the credit card are altered based on a setting in your configuration file.  These settings are in mofpay.conf

Set them to any integer from 1 - 9999

# 11. MAILING MERCHANT
$code_cc_number_one = 0;
$code_cc_number_two = 0;
$code_check_number = 0;

For more detail on how this works see: Docs > Configurations2.html

Note: MOF will not mail credit card numbers unless at least one of the codes are set


 

 

These programs are copyright @ MerchantOrderForm.com, MerchantPal.com 2001