506 replies to this topic

[Taipo]

Oscommerce Security or osc_sec.php by its filename is an include that achieves a level of security for Oscommerce websites...well....that can be achieved from one file included into your webstore.

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

Install:
As simple as it gets.
1/ Upload osc_sec.php into the main catalogs includes folder.
2/ Add a piece of code to both includes/application_top.php and admin/includes/application_top.php, as well as overwrite a piece of faulty code in both those files too (in versions 2.2.1 and earlier). For detailed instructions see the readme.htm file

Download from:
http://addons.oscommerce.com/info/7834

Custom Settings:
There are a number of custom settings you can also set in Oscommerce Security. Those are explained in the readme.htm file included in the package.

The main settings that need your attention are:

$httphost = "www.yoursite.com";
# enter your site host without http:// using this format www.yourwebsite.com

$youremail = "youremail@whatever.com";
# set your email address here so that the server can send you a notification of any action taken

$fromemail = "security@yourwebsite.com";
# set up an email like securityscript@yourdomain.com where the attack notifications will come from

The rest can be left as it is, and is probably safest left as is.

What Oscommerce Security Will Not Do:
This part is important for those trying to prevent more attacks on your sites. If your site has been hacked in the past and you have opted not to completely clean out the web directory and start again with the new version 2.3.1, there is a chance that there may still be rogue files or file code included in your web files. Others have been lucky and have not had this happen, but for those that were not so lucky, and have missed just one of the rogue files added in the attacks, that means that attacks can be launched on your site from within your own site, or triggered via other websites that have also been exploited and are yet to be fixed.

Installing any security file will not prevent this from happening as the only thing that can prevent this is you either going through every php, html and .js file on your site and checking it for exploit code, or saying to hell with it all and install the latest code and starting again (by far the best option although not always the easiest).

What Osc_Sec Will Do (default settings):
- Block incoming attack vectors that are specific to the exploit hole that exists in version 2.2.1 and earlier, using the least amount of banwidth as possible to do so (unless you decide to receive an email of the ban at which point you need to count the amount of bytes being sent in the email).
- Ban the IP address of these attacks. The attacks are specific to Oscommerce so therefore it is by no accident that they occur on your site. Osc_Sec can either add the IP address to the htaccess file or even add the IP address to the IP Trap file if you have IP trap installed, or just block the attack attempt without banning the IP address.
- When an IP is banned, the script in osc_sec ends the execution of the page therefore not only banning the IP address from further exploitation of your site, but also preventing the attack from continuing.
- Whitelisting requests. This is designed to minimize the possibility of malicious code injections into the database. Whitelisting should be standard practice for web script design, however it is often not the case.
- Checks that the application viewing your site is a web browser. Many spam bots are not in fact web browers so therefore do not act as one should.

Optional Extras (not activated by default):
- Prevent security bylass attacks via forged requests
- Check to see if cookies and referer are set before accepting a form post. This can be easily circumvented by an attacker, but its there as an option anyways. Do not activate this if you are using PayPal or any 3rd party payment processor that uses POST as a return call (if none of that makes sense to you then it should just be left in the off position).
- Prevent arbitrary session injections. There are other addons that cover this issue. If your admin directory is secured then you do not need to activate this.
- Automatically send an email to the developer with the ban IP address and the reason for the ban to help improve osc_sec. This is a tiny email at present that has the banned IP address and the 'reason' (a one line sentence why the ip was banned). This is set to off by default, but if you wish, you can set this to '1' if you wish to assist in helping in the development of osc_sec. If your site is heavily attacked then do not activate this as the bandwidth for sending emails will add to your current bandwidth usage.

Edited by Taipo, 10 April 2011 - 11:05 AM.

[altoid]

Taipo, on 10 April 2011 - 11:04 AM, said:

Oscommerce Security or osc_sec.php by its filename is an include that achieves a level of security for Oscommerce websites...well....that can be achieved from one file included into your webstore.

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

Hello there, installing osc_sec has been on my radar for a while now.  The reason I haven't rushed into this is for some time I have been following and installing the various security add ons, and (knock on wood) I don't believe there's been a successful intrusion on my sites as I scan and watch them regularly.

One site I have is a 2.3.1 site. You noted 2.2.1 about, so unless that's typo, the 2.3.1 shop won't get this add on.

On my 2.2 shops, I've taken slightly different approaches for security for each. One runs PHP-IDS and it appears to be rather good at dealing with intrusions.  I am wondering how osc_sec would work with PHP-IDS.  The PHP-IDS add on works in conjunction with a slightly different version of Fimble's IP Trap.

The second 2.2 shop appears does not have PHP-IDS, but has the various security add ons including Fimbles htaccess security codes, Fimbles IP Trap, FWR_Media's  Security Pro, Sam's Anti-hacker Account Mods V1.6, Debb's Bad Behaviour Block, as well as misc tweaks I have learned about through the years.  

Does osc_sec replace  and/or compliment any of those add ons I listed immediately above?

The reason I as is Deb's Bad Behaviour block, basically replaced an Anti XXS add on I had because it covered the same ground and then some.

Thanks for sharing your work.

[puddlec]

tried using AJAX Attribute Manager with this addon. and the product attributes would not show when $arbitrarysession_block = 1, and is fine when $arbitrarysession_block = 0;

how much of an Security issue would it be to have $arbitrarysession_block = 0;

or is there a way to have $arbitrarysession_block = 1; and  attribute manager to work togther.

[Taipo]

Its best to just go with the default settings in Osc_Sec. There are a few addons that attempt to address the issue with the oscommerce session, this is another, but the base settings in which $arbitrarysession_block is set to 0 is sufficient enough to deal with the primary attacks that are being levelled at oscommerce websites.

[Taipo]

altoid, on 11 April 2011 - 06:47 PM, said:

One site I have is a 2.3.1 site. You noted 2.2.1 about, so unless that's typo, the 2.3.1 shop won't get this add on.

The main security issues are with 2.2.1 which is patched in 2.3.1. However a great chunk of users are opting to stay with 2.2.1 for various reasons, so this is a quasi patch of sorts for 2.2.1 users however this addon will work fine on 2.3.1

altoid, on 11 April 2011 - 06:47 PM, said:

On my 2.2 shops, I've taken slightly different approaches for security for each. One runs PHP-IDS and it appears to be rather good at dealing with intrusions.  I am wondering how osc_sec would work with PHP-IDS.  The PHP-IDS add on works in conjunction with a slightly different version of Fimble's IP Trap.

The Digistore version of Oscommerce (version 4.1) has both PHPIDS and Osc_Sec working fine together on it, and I cant see where they would clash.

altoid, on 11 April 2011 - 06:47 PM, said:

The second 2.2 shop appears does not have PHP-IDS, but has the various security add ons including Fimbles htaccess security codes, Fimbles IP Trap, FWR_Media's  Security Pro, Sam's Anti-hacker Account Mods V1.6, Debb's Bad Behaviour Block, as well as misc tweaks I have learned about through the years.  

Osc_Sec will not interfere with any of those, although I have not looked at Sams Anit Hacker Account mod. Osc_Sec does most of what those above do, however each one of them have specialities as well, as does osc_sec.

altoid, on 11 April 2011 - 06:47 PM, said:

Does osc_sec replace  and/or compliment any of those add ons I listed immediately above? The reason I as is Deb's Bad Behaviour block, basically replaced an Anti XXS add on I had because it covered the same ground and then some.

Security in terms of web security is basically in 3 or so layers. Firstly theres the security implimented by your webhost, modsecurity2, suhosin, suPHP etc. However they are broad security measures. The next level down is the htaccess, which again is mostly a broad spectrum control on site usage, directory usage, however it can also be used as a blacklisting system. htaccess controls what happens in a directory irrespective of the files that are in those directories.

Then the next layer of security is that which is imposed by the site code itself, whitelist filtering, blacklist filtering etc etc. Many scripts fail at this level, for example osc2.2.1 and that is where the addons have come into play, mainly, htaccess addons and whitelist/blacklist included files, checking user inputs, filtering what is being added into the database and more.

The restrictions with security via an included file is that it can only successfully protect files that are included in the system itself so if a rogue file exists in the images directory, none of the include file type security measures like PHPIDS, osc_sec or Security Pro can really do much to protect a site against the usage of these added files other than stop them getting there in the first place, and, restricting what they can do with legitimate site files.

So the final level of security is left to the user who has to make sure that if they are hacked, that they clean out their file headers and footers for rogue code, and delete any added files into site directories.

[here2learn]

Hi, I have installed Security Pro 2.0 [link here] and it requires to add the following in the includes/application_top.php file:

After

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

Add

// Security Pro by FWR Media
  include_once DIR_WS_MODULES . 'fwr_media_security_pro.php';
  $security_pro = new Fwr_Media_Security_Pro;
  // If you need to exclude a file from cleansing then you can add it like below
  //$security_pro->addExclusion( 'some_file.php' );
  $security_pro->cleanse( $PHP_SELF );
// End - Security Pro by FWR Media

However, your Osc_Sec requires to replace the above, i.e. this:

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

With this:

// set php_self in the local scope
if ( empty( $PHP_SELF ) ) $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' ] );  

Will any conflict between Security Pro 2.0 and Osc_Sec occur?

Does Security Pro 2.0 depent on the line that your Osc_Sec says have to be changed?

I am using these two security add-ons, plus have the admin folder renamed, its define_language.php and file_manager.php deleted and also, just “for a plus+ security”, a Password Protection added to the folder via CPanel (meaning I have to type the password to be allowed to enter the (renamed) admin directory and THEN enter with the admin login/password.

I think this is more than enough for me to be protected. Of course the permission of files/folder and and the 2 configure.php are all correctly set too.

Edited by here2learn, 15 April 2011 - 09:34 PM.

[Taipo]

I am of the opinion that other than Ultimate Seo Urls 5 and later, there are no other 'addons' (other than version 2.3.1 the latest stable release of Oscommerce) that directly addresses the flaw in the PHP_SELF code - which allows the login.php to create the conditions for a bypass of security.

In Osc_Sec is the Osc 2.3.1 patch for the security hole, that has plagued outdated versions of oscommerce, and include are also some other ways of achieving the same outcome.

Since osc_sec is called before almost anything else in the application_top.php files, it will patch that issue and set the correct $PHP_SELF value. However if another addon which is added further down attempts to also do the same thing and breaks the code, there is not much I can do about that other than pick up the pieces of the PHP_SELF ends up being empty. Hence if(empty....correct back to its original filename...)

So it is safe to add the code as required.

[Taipo]

Osc_Sec2.4[r4] updated
Whats new?
- fixed bug in $_GET whitelisting
- added black list items to block XSS attempts
Download from: http://addons.oscommerce.com/info/7834

[here2learn]

Taipo, on 16 April 2011 - 03:27 AM, said:

I am of the opinion that other than Ultimate Seo Urls 5 and later, there are no other 'addons' (other than version 2.3.1 the latest stable release of Oscommerce) that directly addresses the flaw in the PHP_SELF code - which allows the login.php to create the conditions for a bypass of security.

In Osc_Sec is the Osc 2.3.1 patch for the security hole, that has plagued outdated versions of oscommerce, and include are also some other ways of achieving the same outcome.

Since osc_sec is called before almost anything else in the application_top.php files, it will patch that issue and set the correct $PHP_SELF value. However if another addon which is added further down attempts to also do the same thing and breaks the code, there is not much I can do about that other than pick up the pieces of the PHP_SELF ends up being empty. Hence if(empty....correct back to its original filename...)

So it is safe to add the code as required.

As I understand it, your Osc_Sec will be called first because its code is placed above the code of Security Pro 2.0 in application_top.php, so it'll do its job first, and the rest, if anything left, will be processed by Security Pro 2.0.

Am I correct?

Question 2.
I see that there is a newer version of Osc_Sec (Osc_Sec2.4[r4]). Does this update make the use of Security Pro 2.0 obsolete? If it does what Security Pro 2.0 does and more, I see no reason to use continue using the two add-ons.
Here is the link for it: http://addons.oscommerce.com/info/5752
I think you should look at the code and tell us users, many of whom use Security Pro, whether it is unnecessary when using your Osc_Sec, since your Osc_Sec seems to be a very complete security add-on. We don't need two add-ons performing the same job.

[Taipo]

here2learn, on 16 April 2011 - 03:31 PM, said:

As I understand it, your Osc_Sec will be called first because its code is placed above the code of Security Pro 2.0 in application_top.php, so it'll do its job first, and the rest, if anything left, will be processed by Security Pro 2.0. Am I correct?

Thats correct.

here2learn, on 16 April 2011 - 03:31 PM, said:

Question 2.

Firstly whitelisting security classes have been around for a while, the first one I ever saw that was really affective was CCISecurity in 2003 which was replaced in 2004 by SoapCMS Core Security Class. It dealt with whitelisting, session handling, globals, flooding and more. I use some of the ideas from SoapCMS Core Security Class in Osc_Sec, and many of the concepts in SoapCMS Core Security Class have been taken and used in lots of other CMS packages as well.

I like the premise behind Security Pro 2.0, and if it is ever developed out it could eventually be THE security class that deals with all user inputs. However as it stands its a whitelisting class that generally addresses inputs by only allowing a-z, A-Z, 0-9, ., -, _ and {} within the $_GET array and any other variable you want to check. In most setups that combination of characters are fine, however there are some configurations of Oscommerce as well as addons that will also need = and ? to be allowed as well, so removing these as Security Pro does, may break the way those addons operate.

A class of this sort really should have been stock standard in Oscommerce that way I would not have had to include whitelisting in osc_sec.php

What Osc_Sec is, is a balance between whitelisting and blacklisting, well, in fact whitelisting with fingers in the dike as well, so to speak as well as including the security patch for the admin privileges bypass exploit.

You basically need to ask yourself what is the core purpose which you wish your security addon to achieve for you.

If its filtering of GET requests to reduce the possibilities of XSS type exploits of site code then both Osc_Sec and Site Security Pro do that quite well. If its to block the main Oscommerce security hole without having to upgrade to 2.3.1, then Ultimate SEO URLS 5 and Osc_Sec have the patch code included in their files or upon installing that patch this hole. If its reducing the bandwidth consumption of sites that are under enormous strain from attack requests, then Osc_Sec is the reigning champ in my opinion on that one due to the page die() which ends page execution with only a few bytes sent (where email notification is disabled) when THE attack is detected.

I cannot state that Security Pro 2.0 is obsolete (although Robert Fisher does not seem to have any reservations about calling some other security attempts being obsolete to his contribution....) because I do not know the plans FWR Media have in expanding it out in the future, nor whether or not the Oscommerce developers intend to add it as a stock part of their package, which I think they should...well...some form of overarching whitelisting class at least now that they have patched the big hole by releasing 2.3.1. And I have to confess that at this stage I have not taken a look into Osc3.x to see the security principles they are employing...

Edited by Taipo, 17 April 2011 - 05:49 AM.

[altoid]

Taipo, on 12 April 2011 - 06:08 AM, said:

....................

Thank you for your response to my 11 April inquiry.  I have installed osc_sec on a 2.2 shop and a 2.3 shop I run.  Thanks for your work and help on OCS security.

[Taipo]

Osc_Sec2.4[r6]

Whats New?
- added additional blacklist items

Download from: http://addons.oscommerce.com/info/7834

[here2learn]

Taipo, I think you should add an exclude list to your osc sec. It's something I would use right now, but can't. I have to allow $ and , in a post.

[Taipo]

Osc Sec does not whitelist filter the POST variables. There are a number of banned strings in POST variables, but it is left unfiltered in that manner so you should be able to use $ and , in a post. It does however whitelist filter the GET requests.

[here2learn]

Taipo, on 25 April 2011 - 12:11 AM, said:

Osc Sec does not whitelist filter the POST variables. There are a number of banned strings in POST variables, but it is left unfiltered in that manner so you should be able to use $ and , in a post. It does however whitelist filter the GET requests.

Now I have a more sophisticated script that does not have to submit a form, where I had to use GET to receive its content. The script that I searched for today, and found, calculates (multiply) without having to submit the form. In fact it does not use form. It will automatically display the result in a second box while I am inserting the number to be calculated in the first box, with decimal formatting and all!

Thank you for you attention anyway.

Edited by here2learn, 25 April 2011 - 04:46 AM.

[lisapeden]

Hello Taipo,

I just installed Osc_Sec.php.  Now, when I log in to my admin, I receive a page with the following on it:  "Warning: Cannot modify header information - headers already sent by (output started at /home/lisassti/public_html/admin/includes/application_top.php:469) in /home/lisassti/public_html/admin/includes/functions/general.php on line 156"

After I click on the left arrow (back) button, I am taken back to the log-in page.  If I click on, "Administration," I am then taken to the page where I'm able to "choose an action" and proceed with working on my store.

My question for you is this:  Did I install your add-on incorrectly?

My store is also using STS (Simple Template System)--if that helps.

I've been so stressed out by malicious files constantly being added to my images folder; I was going to dissolve my business--until I found your posts and contribution this morning.  Thank you very, very much for sharing this with the rest of us.

Kindest Regards,

Lisa

Edited by Jan Zonjee, 18 December 2011 - 07:39 AM.

[Taipo]

In the error message was there another bit with a reference to osc_sec.php?

Also can you paste in the settings you are using in osc_sec?
(example settings)

$httphost = "www.somewebsite.com";
$nonGETPOSTReqs = 0;
$chkPostLocation = 0;
$forceHTTPS = 0;
$testExpiredCookie = 1;			
$arbitrarysession_block = 0;

Or email them to me if you wish. rohepotae@gmail.com

[Taipo]

Other than that I cannot think of anything else that could be causing the issue as I have osc_sec.php working on a few sites that have STS installed and they do not have any such errors.

Edited by Taipo, 29 April 2011 - 10:40 AM.

[lisapeden]

Taipo, on 29 April 2011 - 10:00 AM, said:

In the error message was there another bit with a reference to osc_sec.php?

Also can you paste in the settings you are using in osc_sec?
(example settings)

$httphost = "www.somewebsite.com";
$nonGETPOSTReqs = 0;
$chkPostLocation = 0;
$forceHTTPS = 0;
$testExpiredCookie = 1;			
$arbitrarysession_block = 0;

Or email them to me if you wish. rohepotae@gmail.com

[lisapeden]

Taipo, on 29 April 2011 - 10:00 AM, said:

In the error message was there another bit with a reference to osc_sec.php?

Also can you paste in the settings you are using in osc_sec?
(example settings)

$httphost = "www.somewebsite.com";
$nonGETPOSTReqs = 0;
$chkPostLocation = 0;
$forceHTTPS = 0;
$testExpiredCookie = 1;			
$arbitrarysession_block = 0;

Or email them to me if you wish. rohepotae@gmail.com

No, that is the only message that appears when I try to log in.

Here are my settings:


  $currentVersion = "2.4.[r6]";

  $httphost = "LisasStitchingPost.com";   # enter your site host without http:// using this format www.yourwebsite.com
  $nonGETPOSTReqs = 1; # 1 = Prevent security bylass attacks via forged requests, 0 = let the feeding continue
  $chkPostLocation = 0; # 1 = check to see if cookies and referer are set before accepting post vars, 0; don't
  $forceHTTPS = 0; # 1 = redirects to https, 0 = don't, seems to work a little better in OSC than the htaccess rewrite rules
  $testExpiredCookie = 1; # 1 = checks to see if the browser understands what to do with an expired cookie, 0 = don't check
  $arbitrarysession_block = 1; # 1 = prevents arbitrary session injections, 0 = let the feeding continue


A couple of weeks ago, my site developer emailed two .htaccess files to me to install over my site.  They didn't stop the hacks, but is it possible those files I installed are conflicting with osc_sec.php?

Also, is it possible there are still malicious files in my directories?

Thank you in advance, Taipo.  Your add-on is amazing!  I am thrilled with the number of hacks that have been prevented since I installed this yesterday.   You definitely have a gift!

Sincerely,

Lisa