BACKGROUND

Earlier versions of osCommerce and derivatives suffer from security issues where users are able to gain access to the admin functions without proper user authentication.

While web code security is the application developers responsibility, and a patch has been provided by the current developers of osCommerce, many hundreds of thousands of osCommerce users are still using unpatched versions of osCommerce.

PURPOSE

osC_Sec is a 'security include' addon that gets down to the point quick smart.

The primary function of osC_Sec is to provide a specific security patch to the known security issues that have plagued osCommerce based websites. osC_Sec also provides a filtering system to catch and prevent typical database attacks as well as attempt to upload files and use remotely hosted files to do damage to your website content.

Features:
- Checks user input for obsfuscated base_64 encoded strings
- Matches all user input POST variables against a blacklist
- Matches all user input GET variables against a blacklist
- Catch attempts to remotely or locally read or include malicious files
- Filter for MYSQL database injection attempts
- Filter for noDB injection attempts
- Filter cookies for HTTP response splitting and database injection attempts
- Set the correct filename for $PHP_SELF
- Matches all site URLs against a blacklist
- Filters all GET queries against a whitelist of allowed characters
- Checks all server requests types for malformed requests
- Optional writes the IP address of banned requests to the htaccess file, thus preventing further access to the site by that IP
- Prevents direct loading of the osc_Sec files
- Prevent spamming via Tell A Friend scripts
- Lower the information signature leaked by webservers to attackers as part of their intel gathering
- Get the real ip address
- Blocks bad web spidering (DEV)
- Written in PHP 4.x class format
- Optional email notification of attack attempts
- Compatible with IP Trap and Sitemonitor
and more....

Who should use it?
- Users of Oscommerce versions earlier than 2.3
- If your site has been hacked before
- If your site gets heavy attention from malware exploiters and you wish to lower the bandwidth being used by these attacks.

INSTALL:

Upload osc_sec.php and osc.php to your main catalogs /include/ folder. Then in both application_top.php files (one in catalog/include and the other in catalog/admin/include) find and add the following code:

Find:

    // some code to solve compatibility issues
    require(DIR_WS_FUNCTIONS . 'compatibility.php');

On the next line add:

    require_once( DIR_FS_CATALOG . 'includes/osc_sec.php' );

Find: (line may be longer depending on which version of oscommerce you have. It also differs in both application_top.php files)

// set php_self in the local scope
if (!isset($PHP_SELF)) $PHP_SELF = $HTTP_SERVER_VARS['PHP_SELF'];

IMPORTANT: Remove or comment out the above line from both application_top.php files and replace entire line with:

  // set php_self in the local scope
  if( !isset( $PHP_SELF ) ) {
    if ( @phpversion() >= "5.0.0" && ( !ini_get("register_long_arrays" ) || @ini_get("register_long_arrays" ) == "0" || strtolower(@ini_get("register_long_arrays" ) ) == "off" ) ) $HTTP_SERVER_VARS = $_SERVER;
    $PHP_SELF = ( ( ( strlen( ini_get('cgi.fix_pathinfo' ) ) > 0 ) && ( ( bool ) ini_get('cgi.fix_pathinfo' ) == false ) ) || !isset( $HTTP_SERVER_VARS['SCRIPT_NAME' ] ) ) ? basename( $HTTP_SERVER_VARS[ 'PHP_SELF' ] ) : basename( $HTTP_SERVER_VARS[ 'SCRIPT_NAME' ] );
  }
 

Further fixes for osCommerce versions earlier than 2.3.1:

This is for versions that actually have inbuilt admin login protection.

Scroll down catalog/admin/application_top.php and find the following line:

  $redirect = true;
}

After, add the following:

    if ( !isset( $login_request ) || isset( $HTTP_GET_VARS[ 'login_request' ] ) || isset( $HTTP_POST_VARS[ 'login_request' ] ) || isset( $HTTP_COOKIE_VARS[ 'login_request' ] ) || isset( $HTTP_SESSION_VARS[ 'login_request' ] ) || isset( $HTTP_POST_FILES[ 'login_request' ] ) || isset( $HTTP_SERVER_VARS[ 'login_request' ]) ) {
      $redirect = true;
    }

Lastly open catalog/admin/login.php and find the following line:

 Released under the GNU General Public License
*/

After, add the following:

    $login_request = true;

Site edits completed.

If your website does not have an inbuilt method of protecting your admin directory then either change the name of the directory or add htpasswd basic authentication protection.

** Read First **

For the remaining optional settings, we recommend that if you are not experienced in PHP coding enough to understand what the implications of activating these mean, then they are best left in their default settings, disabled. osC_Sec will still function in its intended role to prevent attack attempts.

The Optional Settings: Section by Section

Below is a bit of a romp through each custom setting and what they mean. These can be found in the top of osc.php under the title:

/**
* [[ SETTINGS ]] - stuff to edit
* See: readme.htm for detailed
* instructions.
**/

$timestampOffset

This allows for the optional email report to contain the right time and date.

$nonGETPOSTReqs = 0;

It is possible on some server configurations for an attacker to send a forged request header other than GET, POST, HEAD and OPTIONS. Apache by default interprets all non standard request headers as GET.

Some webhosts filters are already filtering requests, which means a request that is not GET or POST may automatically be prevented, and you may find yours already does this.

However I have found many webservers still vulnerable to this bypass attack so as a safety precaution I have added this section into osc_sec.php.

The best option even if your host is filtering requests is to add the following code to the top of your main shop folders .htaccess file if it isn't already resident there:

<LimitExcept GET POST HEAD OPTIONS> Deny from all </LimitExcept>

It is preferred to have this in the top of your primary .htaccess file, however with $nonGETPOSTReqs enabled (set to 1), osc_sec.php achieves the same outcome. It is ok to have both enabled, even if your host is filtering requests, and that really is the safest option.

If you decide to just use the osc_sec.php $nonGETPOSTReqs feature without the extra htaccess protection then the only difference is that osc_sec.php will ban these requests and add the IP to the htaccess ban list as well as email you if the email option is enabled, to let you know it has done so.

$spiderBlock = 0;

Block a custom list of spiders from accessing your website. Current list is "Baidu", "WebLeacher", "autoemailspider", "MSProxy", "Yeti", "Twiceler", "Mail.Ru". Edit this list if you like to add or remove spiders or just leave this option disabled.

To find the list to edit, open osc_sec.php and scroll to the end around line 1384.

$disable_tellafriend

If you are concerned that attackers are sending spam mail via the Tell A Friend feature on your site, or just want to switch the tell_a_friend off without having to delete the file, then activate this to disable the tell_a_friend.php page from being loaded.

Enabling this will prevent the tell_a_friend.php page from loading and redirect the user back to the main page, therefore an actual attempt to POST to the tell_a_friend.php file when $disable_tellafriend is activated can only be the result of a carefully constructed spam attempt to bypass this script. Hence those advanced attempts to bypass this are then banned.

So any POST attempts are banned, and all other attempts to use the tell_a_friend.php page are redirected back to the index.php page.

Note: Enabling this feature will not remove any of the actual tell_a_friend email fields from other pages on your site where those fields have been added.

$banipaddress = 0;

Setting this to 1 will cause osC_Sec to try to add an IP address of a banned attack attempt to your shops htaccess file. Setting your main shop folders .htaccess to writable will allow osC_Sec to append IPs. This can sometimes mean you have to change the file permissions of the .htaccess file to a writeable setting, usually 666. However just to be safe, if osC_Sec cannot write to the .htaccess it will call a page die as a backup, thus still preventing the attacker from carrying out their attack.

The suggested optimum setting for $banipaddress though is 0 as osC_Sec runs at its least server resource usage by merely preventing the execution of the page rather than having to add IP addresses to the htaccess file.

$useIPTRAP = 0;

osC_Sec can also be set to ban IPs to either htaccess or IP TRAP. So for those that have IP TRAP installed, just set this to 1 and all banned IP addresses will be appended into the IP Trapped text file.

***NOTE*** You can only use $banipaddress or $useIPTRAP, not both at the same time.

$ipTrapBlocked = "";

If you use ipTrap then set the full URL to your blocked.php file (http://www.yoursite.com/blocked.php).
Remember to use https:// if you intend to access your blocked.php page using SSL. It is ok to leave this blank if you do not use ipTrap.

$emailenabled = 0;

If either $banipaddress or $useIPTRAP is enabled, osC_Sec also can email you a detailed summary of any attack attempts that have been banned. If enabled, you can change this back to 0 at any time to disable this feature. If enabled then do not forget to configure the $youremail and $fromemail settings as well so that osC_Sec knows where to send the emails to. If you find you are receiving dozens of these emails per hour I would suggest you disable this feature and just let osC_Sec ban the ip addresses without putting the added strain on the webserver to email out with every ban.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thats all folks

Don't forget to keep osC_Sec updated. Keep up with the latest version at:
http://addons.oscommerce.com/info/8283/

Also discussions at:
- http://www.digistore.co.nz/forum/viewtopic.php?f=10&t=7 or
- http://goo.gl/dQ3jH

or, email rohepotae@gmail.com with any bugs or suggestions.