Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Oscommerce Security - Osc_Sec.php


Taipo

Recommended Posts

Probably the combination of the editor and the length of post might push the execution time to the limit.

 

This can also happen when a server (especially a shared server) is lagging from congestion.

 

If you have access to the php.ini of the webserver then add these lines somewhere near the top:

 

max_input_time = 60
max_execution_time = 300

 

You may find they are already resident in php.ini, if so then up the execution times as above. 300 may seem excessive, but apache has its own timeout which is by default set to 300 anyways.

 

Thanks for that I really don't what to have to change the ini file if I don't have too. Its just strange that the osc_sec.php file is the hold up.

 

It seems to be this function here, mainly the 'for' loop.

function huriWhakamuri($rotator) {
     $nodal = "";
     for ($ctr = 0; $ctr <= strlen($rotator)-1; $ctr++ ) {
         $nodal .= $rotator{strlen($rotator)-$ctr-1};
     }
     return($nodal);
 } 

 

What does this function do?

Link to comment
Share on other sites

  • Replies 598
  • Created
  • Last Reply

It reverses the string to check to see if the code has been written in reverse which is quite common with eval() code on sites that have already been infected by attack code. It is also quite a common post request too due to the botnet type networks making regular requests on osCommerce sites in a more of a random hit and hope fashion to try and strike it lucky.

 

Generally it is not a good idea to filter too much of the POST data and future versions may have a lighter load in the POST department.

 

For now if you want to disable the postshield then do the following.

 

Find:

    postShield($_POST, $oscsec_postb64_blacklist);

replace with

    ( !defined( 'DIR_FS_ADMIN' ) ) ? postShield( $_POST, $oscsec_postb64_blacklist ) : NULL;

 

What that will do is prevent postShield from activating if the requests are coming from the admin directory. However if a post request is made from the catalog area it is still completely filtered by postShield.

 

Using the above I would suggest that you use htpasswd protection if you haven't already implimented it, in your admin directory.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Taipo, I searched the forum about issues running osc_sec with Jack's Site Monitor but could not find anything.

 

Specifically when in admin and running an udpate through the configure routine in site monitor, I get banned/blocked.

 

I believe this is what osc_sec is interested in:

 

SCRIPT_FILENAME = /home/myaccount/public_html/myadminfolder/sitemonitor_configure_setup.php

 

Any guidance on how to deal with that?

 

Thanks

I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Link to comment
Share on other sites

Can you email me the email notification you receive when the ban is activated thanks. [email protected] or just PM it through.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Can you email me the email notification you receive when the ban is activated thanks. [email protected] or just PM it through.

 

Email on the way, thanks

I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Link to comment
Share on other sites

It looks like when you try to set up SiteMonitor, the form attempts to POST in part) the following data:

 

$hackCodeSegments = array('error_reporting(0)', 'base64_decode','<iframe','gzdecode','eval','ob_start("security_update")', 'Goog1e_analist_up', 'eval(gzinflate(base64_decode', 'Web Shell', '@eval', ' header;', 'shell_exec', 'system','SetCookie','Meher Assel', 'nt02', '<script src','r57shell'); //enter any hacker code that you would like to check for

 

osC_Sec is designed to catch and ban any requests attempts that contain phrases like the above and more. In the email notification you sent, osC_Sec caught the query string 'edoced_46esab' (base64_decode in reverse) trying to be POSTed to your site (which is what sitemonitor does when it is setting up which strings should be banned).

 

Fundamentally you have two security scripts trying to achieve the same thing to a similar extent and one banning the other because it tries to enter banned strings via a form as it does.

 

You could employ the temporary fix I posted above but that is no guarantee that osC_Sec will not bump heads again with Sitemonitor at some other point. Along with that, it will certainly diminish the security that osC_Sec brings to your site unless you use htpasswd protection in your admin directory.

 

In the end there is no easy solution to this, I'm afraid its best you use either one security script or the other in the interim until something can be sorted where both can exist within the same space without seeing each other as a threat...

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

It looks like when you try to set up SiteMonitor, the form attempts to POST in part) the following data:

 

$hackCodeSegments = array('error_reporting(0)', 'base64_decode','<iframe','gzdecode','eval','ob_start("security_update")', 'Goog1e_analist_up', 'eval(gzinflate(base64_decode', 'Web Shell', '@eval', ' header;', 'shell_exec', 'system','SetCookie','Meher Assel', 'nt02', '<script src','r57shell'); //enter any hacker code that you would like to check for

 

osC_Sec is designed to catch and ban any requests attempts that contain phrases like the above and more. In the email notification you sent, osC_Sec caught the query string 'edoced_46esab' (base64_decode in reverse) trying to be POSTed to your site (which is what sitemonitor does when it is setting up which strings should be banned).

 

Fundamentally you have two security scripts trying to achieve the same thing to a similar extent and one banning the other because it tries to enter banned strings via a form as it does.

 

You could employ the temporary fix I posted above but that is no guarantee that osC_Sec will not bump heads again with Sitemonitor at some other point. Along with that, it will certainly diminish the security that osC_Sec brings to your site unless you use htpasswd protection in your admin directory.

 

In the end there is no easy solution to this, I'm afraid its best you use either one security script or the other in the interim until something can be sorted where both can exist within the same space without seeing each other as a threat...

 

Taipo,

 

I understand both are really good contributions. Is it necessary to have the site monitor if osc_sec is installed? To be honest I really don't understand site monitor to it fullest so I might do more damage than good if I don't know what I am looking for.

 

Thanks,

 

Mike

Do or Do Not, there is no try.

Link to comment
Share on other sites

I'll leave that one up to you. To be honest I haven't really had a good look through site monitor. It has been accepted by the looks of it as an official inclusion in some of the osCommerce derrivatives, so no doubt many site users must see it as a significant contribution to security. If you want to try using both, then use that code change above along with htpasswd on your admin directory and see if there are any other clashes.

 

The other option if you have a static IP address is to add your static IP to the exclusion list in osC_Sec

 

Find (around line 57):

  $osCSec_exfrmBanlist = array( "216.113.188.202",
                               "216.113.188.203",
                               "216.113.188.204",
                               "216.113.169.205",
                               "66.135.197.160" );

add another IP like this:

  $osCSec_exfrmBanlist = array( "216.113.188.202",
                               "216.113.188.203",
                               "216.113.188.204",
                               "216.113.169.205",
                               "66.135.197.160",
                               "111.222.333.444" );

Replace 111.222.333.444 with your static IP.

 

That will cause osC_Sec to run in a barebones mode for that IP. It doesn't completely disable the security of osC_Sec but it will allow you to bypass the security checks that are catching site monitor.

 

In fact now that I think about it a bit more, glycerine/Craig (from previous conversation), if you are reading this, if you also have a static IP address assigned from your ISP you could try that option as well instead of the code workaround I posted above, which will allow you to post items into your database and bypass the security checks. It would be a lot better security than the option I posted above (but only if you have a static IP).

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

I'll leave that one up to you. To be honest I haven't really had a good look through site monitor. It has been accepted by the looks of it as an official inclusion in some of the osCommerce derrivatives, so no doubt many site users must see it as a significant contribution to security. If you want to try using both, then use that code change above along with htpasswd on your admin directory and see if there are any other clashes.

 

The other option if you have a static IP address is to add your static IP to the exclusion list in osC_Sec

 

Find (around line 57):

  $osCSec_exfrmBanlist = array( "216.113.188.202",
                               "216.113.188.203",
                               "216.113.188.204",
                               "216.113.169.205",
                               "66.135.197.160" );

add another IP like this:

  $osCSec_exfrmBanlist = array( "216.113.188.202",
                               "216.113.188.203",
                               "216.113.188.204",
                               "216.113.169.205",
                               "66.135.197.160",
                               "111.222.333.444" );

Replace 111.222.333.444 with your static IP.

 

That will cause osC_Sec to run in a barebones mode for that IP. It doesn't completely disable the security of osC_Sec but it will allow you to bypass the security checks that are catching site monitor.

 

In fact now that I think about it a bit more, glycerine/Craig (from previous conversation), if you are reading this, if you also have a static IP address assigned from your ISP you could try that option as well instead of the code workaround I posted above, which will allow you to post items into your database and bypass the security checks. It would be a lot better security than the option I posted above (but only if you have a static IP).

 

 

That is good to know. Although I haven't had any issues with running it.

 

Thanks,

 

Mike

Do or Do Not, there is no try.

Link to comment
Share on other sites

It looks like when you try to set up SiteMonitor, the form attempts to POST in part) the following data:

 

$hackCodeSegments = array('error_reporting(0)', 'base64_decode','<iframe','gzdecode','eval','ob_start("security_update")', 'Goog1e_analist_up', 'eval(gzinflate(base64_decode', 'Web Shell', '@eval', ' header;', 'shell_exec', 'system','SetCookie','Meher Assel', 'nt02', '<script src','r57shell'); //enter any hacker code that you would like to check for

 

osC_Sec is designed to catch and ban any requests attempts that contain phrases like the above and more. In the email notification you sent, osC_Sec caught the query string 'edoced_46esab' (base64_decode in reverse) trying to be POSTed to your site (which is what sitemonitor does when it is setting up which strings should be banned).

 

Fundamentally you have two security scripts trying to achieve the same thing to a similar extent and one banning the other because it tries to enter banned strings via a form as it does.

 

You could employ the temporary fix I posted above but that is no guarantee that osC_Sec will not bump heads again with Sitemonitor at some other point. Along with that, it will certainly diminish the security that osC_Sec brings to your site unless you use htpasswd protection in your admin directory.

 

In the end there is no easy solution to this, I'm afraid its best you use either one security script or the other in the interim until something can be sorted where both can exist within the same space without seeing each other as a threat...

 

Hello and thanks for the follow up. I do have my sites password protected so we're good go to there.

 

I have only fundamental coding skills, but let me try to explain Site Monitor and where I see the issue coming from.

 

Site Monitor really doesn't do the same thing that osc_sec does. Site Monitor, when run either manually or via cron compares your store files with a referece file the Site Monitor builds. If there are any differences in any site file size, time of modification, or any file deletion or file addition the report generated will tell you so.

 

I have had osc_sec and site monitor installed together for a while now. In my daily reports from the cron for site monitor I will see that osc_sec has nabbed an intrusion, because the report will show IP_Trapped.txt has been "modified". That's OK, because I know I have osc_sec set up to work with IP Trap and that explains why IP_Trapped.txt was modified.

 

So in simple running mode, both osc_sec and Site Monitor are fine.

 

However, Site Monitor has a configure option, that allows the store owner to make periodic changes if needed. How this issue came up was when I wanted to change the email address to where my site monitor reports are sent, I made the change, clicked the update button in the configure mode, and then got banned. This is all done while in the admin side of the shop.

 

The url it occurs from is:

 

'http://www.myshop.com//myadminfolder/sitemonitor_configure_setup.php?osCAdminID=55a3c5d6afc69997fb66c574679f49fc'

 

Note the osCAdmin ID is appended in this case. But it's the url before that I wanted to show you.

 

When you run the configure, what's going on is that your database is updated, and apparently it's from the database that certain data is gathered to run Site Monitor to your settings.

 

I can back door this matter and go into my database and change that email. That will do the trick.

 

But I wanted to bring this to your attention to see if a tweak could take care of it without doing the backdoor approach.

 

Site Monitor has many benefits so I want to keep that. As well I am happy with the protection that osc_sec is affording so I wish to keep that; it compliments my other security mods nicely I think.

 

Thanks

I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Link to comment
Share on other sites

 

The url it occurs from is:

 

'http://www.myshop.com//myadminfolder/sitemonitor_configure_setup.php?osCAdminID=55a3c5d6afc69997fb66c574679f49fc'

 

Note the osCAdmin ID is appended in this case. But it's the url before that I wanted to show you.

 

Yup, as stated previously, when you run the setup, Sitemonitor tries to POST the contents of this array:

$hackCodeSegments = array('error_reporting(0)', 'base64_decode','<iframe','gzdecode','eval','ob_start("security_update")', 'Goog1e_analist_up', 'eval(gzinflate(base64_decode', 'Web Shell', '@eval', ' header;', 'shell_exec', 'system','SetCookie','Meher Assel', 'nt02', '<script src','r57shell');

 

In doing so it will get caught in the postShield function on osC_Sec which is programmed to catch any attempts to post data with those types of string content. The solution is also as stated, if you have a static IP then add it to the IP list in osC_Sec and when you run Sitemonitors configure_setup.php file, because your IP address is then set to bypass the postShield, osC_Sec will not ban that POST attempt.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Yup, as stated previously, when you run the setup, Sitemonitor tries to POST the contents of this array:

$hackCodeSegments = array('error_reporting(0)', 'base64_decode','<iframe','gzdecode','eval','ob_start("security_update")', 'Goog1e_analist_up', 'eval(gzinflate(base64_decode', 'Web Shell', '@eval', ' header;', 'shell_exec', 'system','SetCookie','Meher Assel', 'nt02', '<script src','r57shell');

 

In doing so it will get caught in the postShield function on osC_Sec which is programmed to catch any attempts to post data with those types of string content. The solution is also as stated, if you have a static IP then add it to the IP list in osC_Sec and when you run Sitemonitors configure_setup.php file, because your IP address is then set to bypass the postShield, osC_Sec will not ban that POST attempt.

 

I currently have a static IP in my 2.2 shops, the 2.3.1 shops don't have that. Yet anyway.

 

I will do the static ip mod you noted on the 2.2 ones and can back door the 2.3.1 shops. Fortunately, once Site Monitor is set up, you don't need to "configure" it often.

 

Thanks again for the time to discuss this.

I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Link to comment
Share on other sites

Sorry if I did not explain this well enough. The static IP I am referring to is not one that your website is hosted with but rather a static IP that your ISP assigns your home connection. If your ISP has assigned you a static IP then add it into the IP list and you should be able to run the sitemonitor_configure_setup.php page without osC_Sec catching it and banning your IP address.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Sorry if I did not explain this well enough. The static IP I am referring to is not one that your website is hosted with but rather a static IP that your ISP assigns your home connection. If your ISP has assigned you a static IP then add it into the IP list and you should be able to run the sitemonitor_configure_setup.php page without osC_Sec catching it and banning your IP address.

 

Thanks for the follow up, and yea...I should have caught that. It's my web host that has assigned me a static IP for SSL purposes. My IP via the ISP isn't static.

 

Well regardless...it's not that big a deal to do my Site Monitor configure stuff by directly modifying the database so that's what I will do.

 

And again, thank you for osc_sec and the support for that.

I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Link to comment
Share on other sites

 

Well regardless...it's not that big a deal to do my Site Monitor configure stuff by directly modifying the database so that's what I will do.

 

 

Correction on this if anyone else runs into this situation. It's not the database you have to modify, it's this file:

 

myadminfolder/sitemonitor_configure_0.php

 

You can modify the settings therein directly, and not have the matter of getting blocked if you try to update the configure settings directly from site monitor.

I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Link to comment
Share on other sites

osC_Sec 2.7[r3]

Whats New?

- removed the reverse check on POST requests to lighten the server load.

- corrected syntax in malformed request string

- $testExpiredCookie is now set by default to disabled in new installs of osC_Sec

- added more blacklist items

 

Update Instructions: copy the osc_sec.php file to your includes directory and overwrite the current file. No need to update the settings file osc.php

 

Install instructions: see the readme.htm

 

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

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

I just added the new update now the script is returning REASON FOR BAN: Returned expired cookie

from legitimate crawlers like alexa and shopwiki.

Any ideas on how to fix this?

Link to comment
Share on other sites

The older version would be doing the same thing. That is why in the newest version $testExpiredCookie is now set by default to disabled. However for those updating from older version you will have to go into the osc.php settings file and disable it as well.

 

Here is a note I included about this particular function:

A note about this cookie function. If activating this function causes session errors to appear on your site then disable it.

 

Its purpose is to catch bots often used to havest information from websites that will later be used to exploit those sites.

 

Although most reputable search spiders are programmed in a way that emulated a web browser so therefore will not return an expired cookie as a proper web browser should act, it is still possible to catch some legitimate web spider servers in this net.

 

No legitimate site visitors will be banned though since all web browsers with cookies activated are set to not return an expired cookie.

 

Open includes/osc.php and find the following line:

 $testExpiredCookie = 1;

 

Change to:

 $testExpiredCookie = 0;

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

osC_Sec 2.7[r4]

Whats New?

- Constructed a better method of determining the catalog directory

- Better method of determining the domain cookie string

- When someone tries to directly access osc_sec.php, a page not found message is now displayed

- Full range of Paypal IP addresses added.

- Fixed issue with htaccess corruptions under certain conditions

 

Update Instructions: Please update both osc.php and osc_sec.php in this update thanks. This will obviously mean resetting the settings in osc.php

 

Install instructions: see the readme.htm

 

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

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

osC_Sec 2.7[r4]

 

Hi!

With osC_Sec 2.7[r3] it's impossible for customers to loggin.

 

The kiss error report gives:

Error Type: [E_NOTICE] Undefined index: oscsec-outdatedhash

On line 107 File includes/osc_sec.php

 

From my own access error system I get:

www.ji-fashion.com/images/account_personal.png

 

404: page not found.

 

HTTP Referer = http://www.ji-fashion.com/account.php

 

And:

www.ji-fashion.com/images/account_notifications.png

 

404: page not found.

 

HTTP Referer = http://www.ji-fashion.com/account.php

 

 

Does the new version fix this?:

 

 

Sara

Link to comment
Share on other sites

Hi!

With osC_Sec 2.7[r3] it's impossible for customers to loggin.

 

The kiss error report gives:

Error Type: [E_NOTICE] Undefined index: oscsec-outdatedhash

On line 107 File includes/osc_sec.php

 

An error notice should not be preventing anyone from logging in. I am assuming also that you have an addon installed that is switching error notices back on after osC_Sec switches them off. Error notices should be off on any production webserver for security reasons as they present more of a security risk being on then the information they give which in most instances are non-critical messages like the undefined index error above.

 

Reinstall both osc.php and osc_sec.php files on your server with the latest files and leave the custom settings as they are set by default, except for whichever IP banning method you are using.

 

Example:

  $timestampOffset = 0;                        # Set the time offset from GMT, example: a setting of -10 is GMT-10 which is Tahiti, 12 is New Zealand
 $httphost = "www.yourwebsite.com";            # enter your site host without http:// using this format www.yourwebsite.com
 $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)
 $GETcleanup = 1;                              # 1 = Clean up $_GET variables, 0 = don't cleanup. If you use FWR_SECURITY_PRO then you can set this to not 0.
 $testExpiredCookie = 0;	                # 1 = Checks to see if the browser understands what to do with an expired cookie, 0 = don't check

 

Just add the www.ji-fashion.com to the $http_host and leave the rest.

 

 

From my own access error system I get:

www.ji-fashion.com/images/account_personal.png

 

404: page not found.

 

HTTP Referer = http://www.ji-fashion.com/account.php

 

And:

www.ji-fashion.com/images/account_notifications.png

 

404: page not found.

 

HTTP Referer = http://www.ji-fashion.com/account.php

 

 

Does the new version fix this?:

 

No, because a missing image is a missing image and is not caused by anything osC_Sec is doing. Do the images account_personal.png and account_notifications.png exist in your images directory? They are either not there or there is some code in your htaccess files that are restricting the site from loading images that end in .png

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

I have been chasing a problem for the last two days where a customer would click add to cart and then the screen goes white. I went through all my files and compared them to stock osc and the modified back ups but found no issues. As a last ditch effort I commented out the osc-sec line in includes/application_top and now everything works. I haave also been receiving several oscsec security alerts for various ips. several of them were never listed by honeypot. Could these have been real customers?

Link to comment
Share on other sites

I have been chasing a problem for the last two days where a customer would click add to cart and then the screen goes white. I went through all my files and compared them to stock osc and the modified back ups but found no issues. As a last ditch effort I commented out the osc-sec line in includes/application_top and now everything works.

 

A few questions:

What settings do you have enabled in osC_Sec?

What version of osCommerce are you using?

What version of apache and PHP is running on the server?

 

I haave also been receiving several oscsec security alerts for various ips. several of them were never listed by honeypot.

Could these have been real customers?

 

What was the ban reason in the email notification? If it was anything other than returning an expired cookie then it will be a hack attempt. If it is an expired cookie then there is a small chance it might be a search spider that returned the expired cookie instead of ignoring it, but other than that there are no browsers around that return expired cookies so it is not possible for a legit customers browser to do so.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Here are my settings:

$nonGETPOSTReqs = 1; # 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)

$GETcleanup = 1; # 1 = Clean up $_GET variables, 0 = don't cleanup. If you use FWR_SECURITY_PRO then you can set this to not 0.

$testExpiredCookie = 0;

$banipaddress = 0; # 1 = adds ip to htaccess for permanent ban, 0 = calls a page die if injection detected

$useIPTRAP = 0; # 1 = add IPs to the IP Trap contribution, 0 = leave it off

$ipTrapBlocked = "http:// www.protoolzonline.com/blocked.php";

I am using RC2 with php 5.

Most recently my own ip was banned because the word flush was in a description for one of the products I was editing. REASON FOR BAN: Posted a banned item: flush.

For the other issue this was the reason:REASON FOR BAN: Exploit attempt using blacklisted request string: .php/login.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...