top 10 ways to secure your oscommerce-based store, security

Here is a list of basic security measures you can carry out to protect your store. Use it as a checklist and consider implementing any missing from your server’s security policy. Some of security steps have certain server requirements that may or may not be available to you, depending on your hosting plan. This post is for stores on Linux servers with LAMP (LinuxApacheMysqlPhp) configurations.

These ideas come from a variety of sources, in particular zen-cart which includes a number of useful security features and recommendations in its cart.

  • Check and Set Permissions
    Permissions are assigned to each folder and file which indicate access rights to specific users or groups.
  • Folders should be a maximum of 755, however certain folders – /images; /admin/backups; /tmp; may require 757 for writing to, depending on your server configuration. All files should be 644 (configure.php files 444 if possible)
  • Disable the ‘Allow Guest to Tell a Friend’ feature
    Some carts allow visitors to the site to send emails through this feature. By disabling this feature, you will prevent non-logged-in customers from using your server to send ‘spam’ email messages.
  • Update your store and module software to the latest versions and patches
    With every new software release, there are usually security or bug fixes which improve the functionality and stability of your store. If you don⬔t upgrade, hackers will be able to easily exploit your websites from known vulnerabilities.
  • Use local htaccess files to restrict script execution, access
    For local htaccess files to work, the server must be setup to allow this, usually in with the command ‘AllowOverride All’ or ‘AllowOverride Limit’ in the apache/conf/httpd.conf file. Check with your hosting company if this is configured.
  • In the htaccess file itself, start by denying access to everything:

  Order Deny,Allow
  Deny from all
  • Then allow access to only certain files:
  • 
      Order Allow,Deny
      Allow from all
    
  • For example, the /images folder:
  • 
      Order Allow,Deny
      Allow from all
    
  • Prevent these variables from being used in say the /cache folder:
  • 
      Order Deny,Allow
      Deny from All
    
    
  • If a folder of downloads, the code can be added so the file is treated automatically as ‘Save As’ and not run as an application:
  • 
      Order Allow, Deny
      Allow from all
      ForceType application/octet-stream
      Header set Content-Disposition attachment
    
  • If you want to prevent snoopers from listing the contents of a folder, there are several ways to do this. The first thing to establish is whether your hosting company already does this via the Apache config file. Ask your hosting company if the following exist in the Apache config file:
    DirectoryIndex index.php
    Options -Indexes -ExecCGI
    (the -ExecCGI is particularly useful as it prevents hackers executing scripts in the folder)
  • If not, ask what the DirectoryIndex is set to (usually it will be “index.php”) – if this is the case, you can add this to a local htaccess file :
    IndexIgnore */*

    or you can create a blank index.php and upload that to the folder

  • Monitor your error and access logs
    You’re looking for suspicious entries here – any links that go to pages not on your site; links that have http after the index.php; that sort of thing. Your store my have /error or /debug folders in its directory structure – check here too.
  • Backup your store regularly
    mySQL database – this can be done through Admin/Tools/Mysql Backup. Use whatever compression is available. Avoid downloading the compressed backup over an unsecured (http://) connection. The zipped backup file is created in admin/backups, so consider how to secure this folder too.
  • Your store’s files – these AREN’T saved using the mySQL backup and must be done separately. Basically you need a copy of everything in /catalog (or ‘root’ which may be called ‘public_html’.)
  • Server settings – more applicable to stores running on their own server (in which case you should have a maintenance program set up already), however check with your hosting company to see how they manage backing up the server configurations.
  • Check with hosting company on what they have done to make your site secure
    Your store can be severely compromised if your hosting company hasn’t correctly secured the server. There are many configuration features that can be enabled by them (eg suHosin, apache config settings and php.ini settings are a few) – so it pays to be clear on what they’re doing to make your store more secure. This is particularly important if you’re running on a shared server and using shared SSL (not recommended.)
  • Get a dedicated SSL certificate and static IP address for your store
    This will help in many ways and if you’re serious about presenting a dependable, secure store, these are essential requirements.
  • Seek help
    If your business warrants, or you still want additional assurance (esp if running forum software on your site, or other scripts outside of your e-cart software), hire a security consultant to check your site regularly and give you peace of mind in exchange for a few dollars.
  • Admin-specific security
    Check this post about securing your admin with specific points related to this important utility’s function. The admin is often the point of entry for hacking attempts.
  • cre loaded – enctype=”multipart/form-data” and payment modules, sagepay form

    Cre Loaded version 6.4.1 still widley uses enctype=”multipart/form-data” for form submission. This would be ok if the forms being submitted involved file uploads or large files, but when payment module forms get zapped with this ‘decoding’ routine, they tend to break. A case in point – the Sagepay Form module.

    The code responsible is in templates/content (or /templates/your template/content) and the file is checkout_confirmation.tpl.php (around line 277 in the CE version) :

    if (ACCOUNT_CONDITIONS_REQUIRED == 'false' ) {
    echo tep_draw_form('checkout_confirmation', $form_action_url, 'post','enctype="multipart/form-data"');
    } else {
    echo tep_draw_form('checkout_confirmation', $form_action_url, 'post','onsubmit="return checkCheckBox(this)" enctype="multipart/form-data"');
    }

    and replace with this :

    if ((ACCOUNT_CONDITIONS_REQUIRED == 'false' ) && ($_SESSION['payment'] == 'sage_pay_form')) {
                echo tep_draw_form('checkout_confirmation', $form_action_url, 'post');
              } elseif ((ACCOUNT_CONDITIONS_REQUIRED == 'true' ) && ($_SESSION['payment'] == 'sage_pay_form')) {
                echo tep_draw_form('checkout_confirmation', $form_action_url, 'post','onsubmit="return checkCheckBox(this)"');
              } elseif (ACCOUNT_CONDITIONS_REQUIRED == 'false') {
                echo tep_draw_form('checkout_confirmation', $form_action_url, 'post','enctype="multipart/form-data"');
              } else {
                echo tep_draw_form('checkout_confirmation', $form_action_url, 'post','onsubmit="return checkCheckBox(this)" enctype="multipart/form-data"');
              }

    cre loaded – how to upgrade from an earlier version

    Upgrading means migrating your earlier version of Cre Loaded to a more recent version – eg 6.2.x (or 6.3.x) to 6.4.x – where the second and third numbers of the versions are different. Updating means migrating between minor versions – eg 6.4.x to 6.4.x – where the third number differs between the two versions. If you want help with updating, have a read of migrating from 6.4.0 to 6.4.1 here.

    The following is an attempt to make the upgrade process a bit easier and is based on an upgrade from Creloaded 6.2 to 6.4.1a.

    ———————————————————————————————————————–

    Before setting off with the Upgrade instructions below, if you currently use the Information infobox and want to upgrade your current 6.2 store’s template, perform the following steps on your existing store:

    1. Switch on Site Maintenance on your store
      Admin >> Configuration >> Site Maintenance >> edit True
    2. Set the Information infobox inactive
      Admin >> Design Controls >> Infobox Configure and set the Information Infobox inactive (red light)
    3. Check which template is your Default template
      Admin >> Design Controls >> Template Manager .. the one in bold is your currently active template.
      There are only two ‘stock’ templates supported in Creloaded 6.4.1 – original_ats and cre63_ats. Both use templates/default/boxes for infoboxes.
      Original_ats uses templates/content for tpl.php files; cre63_ats keeps its tpl.php files in templates/cre63_ats/content. Any other templates will have their own folder in /templates and might use their own /boxes and/or /content folders too.
    4. Keeping the point above in mind, make sure your template has a file called pages.tpl.php.
      If not, go to /templates/content and copy the pages.tpl.php file from there to /templates/your template/content.
    5. Download your /images and your edited /templates/your template/ folders to your computer

    ———————————————————————————————————————–

    The Cre Loaded Upgrade process is described in Cre’s own Installation pdf but it’s a bit tangled up with the New Installation instructions.

    You will need:

    1. The ‘upgrade zip’ containing catalog.zip and the Installation.pdf (the pdf referred to is dated March 15 2010)
    2. Access to your server and database manager – possibly through cPanel or your host’s own control panel, or a free (s)ftp programme like Filezilla
    3. 20-30 minutes

    Once the above is together, proceed as follows:

      • Step One: Create a ‘new_store’ folder on your server
        Use the File Manager in cPanel or even Filezilla for this
      • Step Two: Create a ‘new_store’ database on your mysql server
        Use the MySQL Manager through your control panel – make sure to set Privileges for the User correctly too. Record the database name, username, user password and hostname (this may be ‘localhost’) for later use
      • Step Three: Open the Installation.pdf and go to page 18
        There are a couple of ways of getting the catalog.zip onto your server. One way is as Cre suggests, which involves unzipping all of the folders and files in the catalog.zip to your computer and uploading each via (s)ftp. I wouldn’t recommend this because – it becomes a 12MB upload when unzipped (instead of 6MB); there are over 3500 items to be uploaded and if your connection to the server fails at some point, something may be only partially uploaded and corrupted.

      If you have a Plesk control panel you probably don’t have the option of extracting a .zip through its file manager, in which case you’d have to upload the extracted files and folders from your computer.

      • I’d recommend uploading just the catalog.zip (one file only) to your ‘new_store’ folder and extracting the files on the server. You can do this using Extract from the cPanel File Manager OR if you have command line access, cd to the directory where the catalog.zip is and ‘unzip catalog’ OR ask your host to do this simple process for you.
      • Step Four: Set Permissions on the unzipped folders and files
        There are several folders and files that require permission changes. Once again you can use your control panel or Filezilla (right click on the folder / file >> File Permissions …) to change Permissions.The Installation pdf lists most of the changes required on page 9. Here is the complete list:
        These Files and Folders to Read, Write, eXecute (777) for Owner/Group/Public
        
        /admin/include/configure.php
        /debug/shipwire_debug.txt
        /include/configure.php
        /includes/header_tags.php 
        /includes/languages/english/mainpage.php   
        /includes/languages/english/header_tags.php 
        (7)
        
        /admin/backups 
        /admin/images/graphs 
        /cache 
        /images 
        /images/banners 
        /images/logo 
        /images/events_images 
        /debug 
        /tmp 
        /temp 
        /library - if Pro or B2B 
        (10/11 if Pro or B2B)
        Note: /debug/shipwire_debug.txt is also required to have Read/Write/Execute by Owner/Group (777) permissions set.
      • Step Five: The Upgrade Screen
        Now turn to page 19 of the Installation pdf to continue with the upgrade instructions. Your screen will look like this:

        Just choose the ‘PCI Upgrade’ option here, whether your Store held credit card information or not. It doesn’t make any difference if you try to remove non-existent information.The next screen is a Pre-Install Check …. everything must be green to proceed. If you didn’t correct the Permissions in Step Four, you’ll be seeing red here.

        The next screen asks you to confirm the (absolute) pathway to your existing Cre Store that is being upgraded, as per page 20 of the Installation pdf. The follows a check and confirmation of this path (page 21.)
      • Step Six: Follow the Installation pdf through pages 21 – 28
        The rest of the Installation pdf will take you through through Database Settings and Upgrade, PCI Compliance, Summarize your Server Configuration and cover resetting Permissions, Cre Secure and your Payment Modules etc.
      • Step Seven: Template and Image folder upload
        Upload your old store’s /images and /template/your template folders that you downloaded prior to these six steps. Remember to set permissions for these too.

      Other recommendations:

      • delete your /Upgrade folder from the server
      • check all permissions on files are set to 644 at most (configure files 444) and on folders to 755 (or 757, avoid 777)
      • protect your Admin folder
      • set up various htaccess protection methods for other folders and files too if possible.

      12 things you should do to improve your oscommerce-based admin security

      Here are some ideas from protecting access to your ‘admin’ area – notice the use of ‘admin’ because one of the first moves is to change its name.
      These ideas come from a variety of sources, in particular zen-cart which includes a number of useful security features and recommendations in its cart.

      1. Rename your Admin folder
        - Edit the admin/includes/configure.php file. Find and replace all instances of /admin/ with /’your new admin name’/
        - Rename the Admin folder with ‘your new admin name’
      2. Delete the files ‘admin’/file_manager.php and ‘admin’/define_language.php
      3. Don’t reveal the new name of your ‘Admin’ folder
        - Remove any reference to the ‘Admin’ folder name from catalog/robots.txt.
        This file is readable by anyone at anytime. So anything entered here can be used to map your Store.
      4. Limit access to ‘Admin’ and remove old or unused ‘Admin’ accounts
        - htaccess rules can be used here. If your Apache server allows local htaccess files to ‘override’ its default settings (check with your host) then you can create an .htaccess file in the ‘admin’ folder and add the following: 

        # deny *everything*
        
          Order Allow,Deny
          Deny from all
        
        
        # but now allow just *certain* necessary files:
        
          Order Allow,Deny
          Allow from all
        

        This snippet above will only allow certain file types to be run (as specified in the list php|js|css|jpg|gif|png.) Simply add more extensions with a pipe | to broaden. If you want to lock access to the ‘admin’ area to a range of Ip addresses you use, try:

        # allow only your IP addresses
        
          Order Deny,Allow
          Deny from all
          Allow from 123.123
          Allow from 456.456
        

        Note the above rule uses only the first two groups of numbers from two Ip addresses. This is because many people are on dynamically assigned IPs which although they do change (infrequently), they often don’t vary that much. If you have a static or dedicated IP address when you connect to the Net, you won’t have this problem.
        - set permissions on all folders to 755, all files to 644 (or 444 read only if configure.php). There are some exceptions here: ‘admin’/backups and ‘admin’/images will require write permissions of 757. These may be able to be protected using htaccess rules however.
        - delete old ‘admin’ accounts, especially ‘demo’ or ‘guest’ accounts or those created for temporary users.
      5. Change ‘Admin’ passwords regularly and password protect your ‘admin’ folder
        - to make a tough password, use a password generator like the PCTools Security Password Generator and store them in a password vault like KeePass
        - many control panels (like cPanel and Plesk) offer a simple ‘Password Protect Folder’ utility. This is a good idea, although it does mean you will have to log in twice to the ‘admin’ the first time (once in the popup, then again in the actual login.) However if you have cookies enabled for the session, you only have to do this once while the browser is open. If you don’t have access to such a utility, here are the steps to create your own password protected folder:
        Add your version of this to your ‘admin/.htaccess file (making sure you change the values in lines 2 & 3 after AuthName and AuthUserFile):
        AuthType Basic
        AuthName "whatever you would like it to ask you"
        AuthUserFile /absolute/path/to/your/new/.htpasswd
        Require valid-user

        (I’d recommend putting the .htpasswd file in a folder inaccessible from the web, with its own .htaccess file containing:)
        
          order allow,deny
          deny from all
        

        Use an htpasswd generator to create and encrypt your password – like this one at dynamicdrive.com
        Copy and upload/save the .htpasswd file in its ‘hidden from the web’ location. Done!
      6. Don’t reveal the name of your ‘Admin’ folder on printed invoices, packing slips
        - If you print invoices or packing slips, switch off printing the url path on the page.
        For Internet Explorer: File >> Page Setup >> remove this two character combination: “&u” from the header or footer text box.
        For Firefox: File >> Page Setup >> Margins & Header/Footer >> set all of the drop downs to –blank–.
      7. Set up ‘Admin’ under another domain or subdomain
      8. Use secure Usernames and Passwords
        - If you have work done by a developer or coder who needs access to your admin, use a temporary username and password that you delete afterwards. Use a password generator (like the PCTools Generator mentioned above) and store them in a password vault (like KeePass)
      9. Check access dates in the database
        - If you do have developers etc access your ‘Admin’, use phpMyAdmin and browse the admin table for the admin id row of the account, looking at date_modified. This will show the last access date of that account. Ideally though issue temporary admin access to developers. Many versions of oscommerce-based carts (including zen-cart and oscommerce 2.3.x) now have admin logs so you can see a record of logins (and login attempts.)
      10. Be security conscious when accessing your ‘Admin’ account
        Not best practice to :
        - access the Admin from a public use computer or public wireless hotspot
        - write login details on a piece of paper stuck to the computer or wall in front of you
        - use ‘password’ as your password (lol)
      11. Don’t advertise the version of the Store software you’re running via the ‘admin’
        - Even if you’ve renamed your ‘admin’ folder (as mentioned back at the top of this post eh), there’s not a lot to be gained from advertising which version of the software you’re patched to:

        If a security fault was discovered in this version, why advertise you may not have patched? In this example using Cre Loaded, remove around line 135 -137 from ‘admin’/login.php:
           
              
              
              
         
         
      12. When using the ‘admin’ panel …
        - use only one browser tab to access your admin area
        - avoid visiting other sites when your browser has an active admin login session enabled, even in another tab
        - always log out of your admin when not using it

      cre loaded – how to update from version 6.4.0 to version 6.4.1

      This process is best described as ‘updating’ and I’d only recommend doing this between minor versions in sequence – eg 6.3.1 -> 6.3.2, or 6.4.0 -> 6.4.1. If you’re going to jump from 6.3.x to 6.4.x I’d recommend reading up on how to upgrade between major versions.

      ‘Updating’ means:

      • your store’s current database gets updated by any changes in the update update patch for the database
      • you manually overwrite your old store’s files and folders using the folders/files from the update
      • you don’t have to create a new blank database or change permissions on folders/files

      Sounds straight forward? Should be, but the 6.4.0 -> 6.4.1 update isn’t for some.
      Here are the steps I used:

      Step 1: make sure you download and extract the correct update to your computer (this is a Pro version update example)

      choose the correct cre loaded update example pro version

      After extracting the contents from the patch itself, you should have catalog.zip and a pdf Guide to Installation. Delete this guide as nothing in it applies to Updating, only Upgrading. Instead go to the Cre Loaded site and scan the only information they give on the Updating process: Here is Cre Loaded’s official document on updating.

      Step 2: backup your current database and store
      There are a couple of reasons for doing this – the obvious (if you stuff up the update, you’ve still got the original files) but also if you have a modified site you may lose some or all of these modifications in the update (so you’ll need your originals to get back on track.)

      Step 3: upload and overwrite your store’s folders and files as per the update

      Step 4: type the url to your store with /upgrade on the end – eg www.mystore.com/upgrade

      This will bring up the update page – confusingly called the ‘Upgrade Wizard’ with blah about versions 6.2 and 6.3 and no mention of 6.4.0.

      cre loaded update upgrade screen

      Once you click the big blue Update button you might be lucky and get this:

      You have successfully updated your Cre Loaded database

      … or like me, you’ll get this ominous screen of fail:

      cre loaded configuration files error on update

      Why the ‘Existing configuration files cannot be accessed’ message? Because when Cre wrote the upgrade scripts, they assumed that everyone’s Admin folder is called, well, ‘Admin.’ But if you’ve decided to make hackers work a little harder and renamed your store’s Admin folder to something other than ‘Admin’, this is why you’re seeing this error.

      How to fix this: here’s the top part of the script that is at fault:

      /upgrade/templates/pages/upgrade.php

      
                      

      The lines you need to edit are 29, 30 and 34, replacing the word ‘youradminfolder’ with the actual name of your admin folder.
      Try Step 4 again and your database should be successfully updated.

      Maybe next time Cre will create a better updater … please.

      ideas and help with oscommerce-based shopping carts