484 replies to this topic

[Taipo]

casper, on 15 May 2011, 18:53, said:

Hi,

Thank you for quick reply:)
I have this in my configure.php

define('DIR_FS_CATALOG', dirname($HTTP_SERVER_VARS['SCRIPT_FILENAME']));

Do I need to change this to what you mentioned?

Thank you again!!

I would be interested in what version of osCommerce you are using. I have a few versions installed here to test on and none of them have the dir_fs_catalog defined in that manner (just for my testing purposes).

So in that case I would leave that as it is and change the require in both includes/application_top.php files to the actual file path, as well as the two references in osc_sec.php

That still does not address the file compression issue which sounds like it is a conflict with another addon that backs up files maybe?

[Taipo]

casper, on 15 May 2011, 18:56, said:

Oh, and I had another question.

Does this work as same as this contribution??

That addon is trying to achieve the same outcome and on a great majority of webservers it would patch the admin bypass exploit aspect the range of problems with the earlier versions of oscommerce, but on some servers where PHP is configured differently that patch alone will break the $current_page code. However it is certainly better than nothing. The best patch though is the one in Oscommerce 2.3.1 which has been copied into osC_Sec along with a few other backup methods of achieving the same result.

[Taipo]

osC_Sec 2.4[r8] update
Whats New?
- fixed write access message so that it no longer displays the root path on install
- added a whitelist for IP addresses to protect from accidentally banning 3rd party payment callbacks like Paypal
- added more blacklist items
- developed out method 2 of the php_self check

Download from: http://www.oscommerce.com/community/contributions,7834

[casper]

Taipo, on 16 May 2011, 01:15, said:

That addon is trying to achieve the same outcome and on a great majority of webservers it would patch the admin bypass exploit aspect the range of problems with the earlier versions of oscommerce, but on some servers where PHP is configured differently that patch alone will break the $current_page code. However it is certainly better than nothing. The best patch though is the one in Oscommerce 2.3.1 which has been copied into osC_Sec along with a few other backup methods of achieving the same result.

Thank you Taipo.
I tried to find out what version I am using but I could not find that info.
It has 2003 in it so it is pretty old for sure, but it has been heavily modified and I have not taken time to upgrade whole store...
I love this community. I learned so much from people like you. I had no knowledge when I started.

I will have to play around some more what works with my store.

Thank you again!!

[Taipo]

I did manage to test osC_Sec on one of the earlier versions of osCommerce and it seemed to work ok, however I assume that it will be an addon that is causing that error in question, something associated with backing up the site using gzip.

[Taipo]

osC_Sec_2.4[r9] Updated
Whats new?
- improved the way the phpSelf function checks for faulty $PHP_SELF results
- fixed issues with the banning of directly viewing osC_Sec.php

Download from: http://www.oscommerce.com/community/contributions,7834

[Grakkam]

Taipo, on 17 May 2011, 05:17, said:

osC_Sec_2.4[r9] Updated

Hiya! I really appreciate all the work you put into this. Osc Sec is a vital add-on, and you're doing a great job!

I was wondering, though, if you would consider putting the settings in a separate file? This would make it easier to install new updates.

Cheers!

[Taipo]

Actually thats a good suggestion, thanks for that. I will set that up for the next update which will be version 2.5

Currently 2.4[r9a] is the latest which has a number of little comment removals in it that I missed in revision 9.

[germ]

This is just an observation on my part so don't anyone take this the wrong way.

I'm not "poking holes in" or trying to detract from anyone's great work.

As I said - this is just an observation.

It looks like it hasn't come up yet but this code in the contribution:

  } elseif ( strtolower( $_SERVER[ "HTTPS" ] ) != "on" ) {
        $oscsecHTTP = "http://";
  }

Will not accurately determine if SSL is active or not on every server.

$_SERVER[ "HTTPS" ] is undefined on some servers even if SSL is active.

On some servers it's not set to "on" when active.

For example on 1AND1 Hosting you have to use this to detect SSL:

getenv('HTTPS') == '1'

Given the things I've had to have store owners change in the SSL Implementation Help support thread to get SSL to be detected by the store.

$_SERVER[ "HTTPS" ] is supposed to work (it even says that on the php.net site) but it doesn't on every site that uses SSL.

If you already have SSL installed and working on your site, check your /catalog/includes/application_top.php for what it uses to successfully detect SSL.

The default code is this:

// set the type of request (secure or not)
  $request_type = (getenv('HTTPS') == 'on') ? 'SSL' : 'NONSSL';

If you have something else other than that to detect SSL you'll probably have to integrate whatever you use into the Osc_Sec file.

As far as I know there is no "Holy Grail" piece of code that will detect SSL 100% all the time on every server.

That part of the reason I started the SSL implementation help thread.

[Taipo]

Good point. Unfortunately I have yet to rip that section out of osC_Sec which is why it is still there. But its on the list for removal as it is not as needed as I first envisaged when I first began looking for security holes in osCommerce. Probably in the next release it will be gone.

[Taipo]

osC_Sec_2.5[r1] updated
Whats New?
- IMPORTANT: osC_Sec is now split into two files (thanks to a suggestion by Grakkam) osc.php which contains the settings, and the rest is in osc_sec.php. So from now onward updating will mean simply overwriting the osc_sec.php file which contains the actual code.
- removed the SSL code from osC_Sec as it is no longer needed and as someone else pointed out, there is already an addon that deals with SSL issues.
- updated the way osC_Sec determines SSL (thanks to germ)

Download full fileset from: http://www.oscommerce.com/community/contributions,7834

[fenerbahce]

Great contribution. Already using it on a few sites. My problem is with Ajax Attribute Manager When I use osC_Sec with Ajax Attribute Manager the remove attribute button does not remove the attribute from the product. Is there anything I can do to allow Ajax Attribute Manager to work with osC_Sec?

[Taipo]

Can you paste in the settings you are using in osc_sec thanks.

[fenerbahce]

Taipo, on 19 May 2011, 04:54, said:

Can you paste in the settings you are using in osc_sec thanks.

I am using the latest version and the settings are as follows. I have played with different setting combinations but no luck so far:

$nonGETPOSTReqs = 0; # 1 = Prevent security bylass attacks via forged requests, 0 = let it as it is
$chkPostLocation = 0; # 1 = check to see if cookies and referer are set before accepting post vars, 0; don't (especially if using Paypal)
$forceHTTPS = 0; # 1 = redirects everything to https, 0 = don't
$testExpiredCookie = 1; # 1 = checks to see if the browser understands what to do with an expired cookie, 0 = don't check
$arbitrarysession_block = 0; # 1 = prevents arbitrary session injections, 0 = leave it as it is

[Taipo]

I have had one other user complain of the same thing with the ajax addon but theirs was solved by disabling $arbitrarysession_block.

Since you have that disabled that really only leaves you with commenting out a couple of sections of osC_Sec which update variables and values.

So I am just going to take an educated guess here. Find the following section around line 274:

        $getvariables = $_GET;
        $getvariables = array_keys( $getvariables );
        if( $getvariables !== array() ) {
            $count = 0;
            while( $count < count( $getvariables ) ) {
                   $_GET[$getvariables[$count]] = scrubster( $_GET[$getvariables[$count]] );
            $count++;
            }
        }

Replace with the following:

        $getvariables = $_GET;
        $getvariables = array_keys( $getvariables );
        if( $getvariables !== array() ) {
            $count = 0;
            while( $count < count( $getvariables ) ) {
            #       $_GET[$getvariables[$count]] = scrubster( $_GET[$getvariables[$count]] );
            $count++;
            }
        }

That is the main piece that actually updates the GET array. There is one more piece in the code that does so, but try that first and let me know if that corrects the problem.

[fenerbahce]

Taipo, on 19 May 2011, 09:42, said:

I have had one other user complain of the same thing with the ajax addon but theirs was solved by disabling $arbitrarysession_block.

Since you have that disabled that really only leaves you with commenting out a couple of sections of osC_Sec which update variables and values.

So I am just going to take an educated guess here. Find the following section around line 274:

        $getvariables = $_GET;
        $getvariables = array_keys( $getvariables );
        if( $getvariables !== array() ) {
            $count = 0;
            while( $count < count( $getvariables ) ) {
                   $_GET[$getvariables[$count]] = scrubster( $_GET[$getvariables[$count]] );
            $count++;
            }
        }

Replace with the following:

        $getvariables = $_GET;
        $getvariables = array_keys( $getvariables );
        if( $getvariables !== array() ) {
            $count = 0;
            while( $count < count( $getvariables ) ) {
            #       $_GET[$getvariables[$count]] = scrubster( $_GET[$getvariables[$count]] );
            $count++;
            }
        }

That is the main piece that actually updates the GET array. There is one more piece in the code that does so, but try that first and let me know if that corrects the problem.

I really appreciate your help. This has fixed my problem. Thank you.

[Taipo]

The problem seems offhand to be a combination of possible conflicts with the way the attributes manager uses urlencode and how osC_Sec uses urldecode, and perhaps even addslashes. My problem is I cannot replicate the error you are getting here in order to properly fix this in osC_Sec if that is even possible. I will keep working on it.

[Taipo]

osC_Sec_2.5[r2] Updated
Whats New?
- Shifted the timezone settings into the settings area. These determine the accuracy of the timestamp when an exploit attempt is detected. This will mean that you will have to update the settings file osc.php as well as the content file osc_sec.php (hopefully last time)
- Made the cleanup of the $_GET variables optional again due to conflicts with some addons. A setting has been added to osc.php called $GETcleanup. It is by default set to activated so no changes needed for most users.
- Removed surplus settings from osc.php which were no longer used

Download from: http://www.oscommerce.com/community/contributions,7834

fenerbahce: this should make it easier for you in the future to update osC_Sec as you can just set $GETcleanup to 0 in the osc.php file without having to reapply that change above everytime you update osC_Sec.

[Roll2Dice]

What do you say about this exploit?

http://www.exploit-db.com/exploits/17285/ (OSC 2.3.1: Remote File Upload Vulnerability : Banner Manager)

I haven't tried it myself, but osC Sec should stop this one without any problems, right?

[Taipo]

I made a comment about it below
http://forums.oscommerce.com/topic/375408-231-bug/

2.3.1 is patched against this, so its a bogus exploit, or one that has not been tested on a fresh install of osCommerce 2.3.1

And yes osC_Sec will block/ban this as will any addon that looks for the combination of '.php/login'