Latest News: (loading..)
burt

Updated Security Thread

84 posts in this topic

Annette,

 

You more than likely received the error message when trying to edit the configure.php because you had the file permissions set correctly ! Yes, correctly. The TWO configure.php files should have permissions of 444, which will not allow you to over write them. So, when you edited the file and tried to upload it back to the server, you received the error. In future, rename the old configure.php to configure1.php (or something similar) and then upload the edited file to the server.

 

ALWAYS remember to change the file permissions back to 444 for the two configure.php files.

 

 

 

Chris

Share this post


Link to post
Share on other sites

Juto - that piece of code deals with POST'd items. Which is now taken care of by osc_sec.

Share this post


Link to post
Share on other sites

While osC_Sec does whitelist filter the GET requests that is similar in concept that is also used in FWR Security Pro 2.0, like Security Pro 2.0 osC_Sec does not whitelist filter POST inputs. In its first incarnation I originally coded osC_Sec to do so but found it too problematic, so opted for a blacklisting of POST string combinations that should not appear anywhere in POST values in osCommerce. While not the optimum, I thought it was better than no filtering of POST all.

 

The problem is that there are items that are ok in POST variables, but dangerous in GET, and a few in the viceversa, so its coming up with the right balance between the two without cramping the style of site visitors and owners.

 

That code back a page is a pretty good attempt at constructing a POST whitelisting, and if I ever add a POST whitelist function into osC_Sec it would be along those lines.

Share this post


Link to post
Share on other sites

Hi Burt. Thanks for answering I will keep it in view of what taipo wrote :)

 

Sara

Share this post


Link to post
Share on other sites

Hi Taipo and thanks for your osc_sec :)

 

I have added the code in htaccess like so:

 

RewriteEngine on

RewriteBase /

#Added osC_Sec

<LimitExcept GET POST HEAD>

Deny from all

</LimitExcept>

Options +FollowSymlinks

 

Is this correct?

 

Sara

Share this post


Link to post
Share on other sites

Hi Taipo, I just looked into what the kiss error handler displayed and saw:

 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Date / Time: 29-05-2011 17:22:25

Error Type: [E_NOTICE] Undefined variable: getHexvars

On line 247

File includes/osc_sec.php

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Date / Time: 29-05-2011 17:22:25

Error Type: [E_NOTICE] Undefined variable: _SESSION

On line 379

File includes/osc_sec.php

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Date / Time: 29-05-2011 17:22:25

Error Type: [E_NOTICE] Use of undefined constant DIR_WS_ADMIN - assumed 'DIR_WS_ADMIN'

On line 412

File includes/osc_sec.php

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Date / Time: 29-05-2011 17:22:25

Error Type: [E_NOTICE] Use of undefined constant DIR_WS_ADMIN - assumed 'DIR_WS_ADMIN'

On line 426

File includes/osc_sec.php

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

I suppose you need to have a look into this?

 

Sara

Share this post


Link to post
Share on other sites

Error notices are generally of use in a development server and should be disabled in production servers as they are not critical to site security or operation. Some of the notices above are in relation to intentional coding but none of the notices will affect the way a site operates except for the fact that having E_NOTICE enabled in itself is a waste of server resources on a production server.

 

If you do not have access to the php.ini on your webserver then add this code to the top of your application_top.php files.

  error_reporting(6135);

 

This has the same affect as setting E_ALL & ~E_NOTICE in php.ini

Share this post


Link to post
Share on other sites

Note that a few people refer to osCommerce 2.2.1 - which is causing some confusion.

 

2.2.1 does not exist and never has existed.

 

2.3.1

2.3.0

2.2 rc2a

2.2 rc2

2.2 rc1

2.2 ms2

2.2 ms1

 

There are more, but these would be the main osCommerce versions in use now. I am guessing that 2.2.1 refers to 2.2 ms1.

 

2.3.x versions of osCommerce fix a lot of insecurities that were a major downfall of 2.2 versions. Hence why I have posted what needs to be done for each version in the post up there. Hopefully that's understandable?

Edited by burt

Share this post


Link to post
Share on other sites

The other security thread is good, but times have moved on. Here are my base suggestions (in no particualr order) for securing a unhacked site;

 

1. Security Pro from FWR Media

2. OSC SEC from Taipo

3. Filesafe from FWR Media

4. Add htaccess to all public folders

5. Rename /admin/ and htpasswd it

6. Remove references to (newly renamed) admin area in outgoing emails

7. Add extra login parameter (JanZ)

8. Fix $PHP_SELF spoofability

 

Bad Conduct from Debs (undecided on this, I am still "road-testing" it).

 

I am not in favour of IP trapping, as most hackers don't use their own IP addresses.

 

If anyone has any extra thoughts on this, please post.

 

For securing a hacked site - exactly the same, but make sure that the hack is cleaned out first. This can be done by manually inspecting the files and removing any files/code that is not supposed to be there. Or by re-installing from a known unhacked backup. Or of course, starting from scratch with a brand new install of oscommerce.

hi,

 

i am installing a new oscommerce shop. it is version 2.3.1 therefore i have done 1, 3, 5, 6 from your list. 7 was already done when I went to do it, and am i correct in thinking i do not need to do 2, 4 and 8 with my 2.3.1 version?

 

lastly, how do i check that my

 

6. Remove references to (newly renamed) admin area in outgoing emails

 

has worked?

 

thanks

Share this post


Link to post
Share on other sites

In securing your site, you could also add this:

 

In your admin htaccess add before the htpasswd check:

# Protect files and directories from prying eyes.

<FilesMatch "...">

Order deny,allow

Deny from all

# allow your ip address's:

#Office:

allow from 12.34.56.78

#Home:

allow from 87.65.43.21

</FilesMatch>

 

You could also remove the lines allow from...

When you need to access the admin area first ftp to your site and change the above "allow from..."

 

In your catalog's htaccess:

#Instead of showing access denied redirect to index.php

#Like so

ErrorDocument 403 /index.php?id=403

This means that even if the hacker know the name of your admin area they will be shown your sites landing page...

 

Sara

Share this post


Link to post
Share on other sites

Hi! I have just installed r6 and in

// Preset other variables

 

I added:

$hasHexvars = False;

 

 

Now, all warnings are gone :)

 

Sara

Share this post


Link to post
Share on other sites

.....am i correct in thinking i do not need to do 2, 4 and 8 with my 2.3.1 version?

 

In 2.3.1 you do not need to do anything as it is basically a secure package in that to date there have been no serious security issues reported about it other than the issue I raised somewhere else about malformed admin strings could be used to coerce an admin to log into their own site via the link. But that is less of an issue it seems than any of the previous security issues from earlier versions of osCommerce.

 

osC_Sec was designed for users of osCommerce who persist in using versions earlier than 2.3.1. It has in it some of the patches from 2.3.1 including the $PHP_SELF patch to the admin bypass exploit. So 2 and 8 (which are actually both in osC_Sec) are not a necessity to 2.3.1, only a necessity to earlier versions.

 

But what you will find is that because osCommerce was heavily attacked and still is being heavily assaulted by attackers, a lot of your site bandwidth will be consumed dealing with bogus requests trying to exploit these old security holes that are no longer relevant to osCommerce 2.3.1

 

Because osC_Sec kills those requests before the page can load, it will reduce your bandwidth consumption quite considerably. An example of this is on one of my honeypot sites where I have set osC_Sec to just prevent an attack but not ban the IP address. The attack itself comes in groups of up to 20 repeated requests in a matter of a few seconds. My guess is that the tools being used work in a hammering motion. So while 2.3.1 is patched against the attempts, thats 20 page loads that resulted in the server redirecting the user to the login page as it should. But that is a lot of wasted resources on your website just because you are using osCommerce.

 

So having a security script that catches the first attempt and adds the IP address to a ban list can reduce the resources being used up on your website, considerably....even if all it is doing is that....reducing a 20 requests attack to a few bytes of data transferred.

 

To use osC_Sec in that manner, set all the settings to 0 including emails except for the banipaddress setting and osC_Sec will work purely as a bandwidth saver for 2.3.1

shawaj likes this

Share this post


Link to post
Share on other sites

In saying that above, it also does not hurt one bit to take extra security measures with 2.3.1 like renaming the admin directory or at least making sure it has htaccess htpasswd protection.

shawaj likes this

Share this post


Link to post
Share on other sites

hi Taipo,

 

only just noticed your reply...and thanks for the great detail!! extremely helpful.

 

with the ip ban list...how often does this "refresh" because obviously most hackers will be hiding behind a different ip, and also a lot of people have dynamic ips so they wont always be the same? would it still block the traffic even without ban ip enabled?

 

and does anyone know how to check if i have correctly got rid of the X PHP headers in my emails?

 

thanks once again!

Share this post


Link to post
Share on other sites

osC_Sec will end the page load if an attack is detected and send the browser/client a 403 ban request header, irregardless of whether you enable $banipaddress or not.

Share this post


Link to post
Share on other sites
4. Add htaccess to all public folders {

2.2rc2a and lower

a. If you still run pre 2.3.1 cart, use the .htaccess files from a 2.3.1 installation.

Example: https://github.com/o...mages/.htaccess

}

 

I have an htaccess file for the root directory. However, I’m not exactly sure what should be in it. Are there any examples as to what to include in the htaccess for the root?

 

I have installed the htaccess file recommended for the catalog/images directory. It contains the following:

# .htaccess to prevent directory listing
IndexIgnore *

# This is used to restrict access to this folder to anything other than images
# Prevents any script files from being accessed from the images folder
<FilesMatch "\.(php([0-9]|s)?|s?p?html|cgi|pl|exe)$">
  Order Deny,Allow
  Deny from all
</FilesMatch>

 

I have also seen the following recommended for the catalog/images directory:

php_flag engine off
<Files ~ "\.(php*|s?p?html|cgi|pl|ini)$">
deny from all
</Files>

 

Should I include the "php_flag engine off" in the htaccess file for the images directory?

 

I'm confused about the term "pubic folder." Other than the image directory, what directories are considered “public folders?” I understand the need to protect the images directory from hidden executable code. Should the htacces used in the images folder also be used in other "public folders" or do other public folders require a different type of htaccess file?

 

Sorry for showing my ignorance. I just want to get it right. Thank you for your help.

Share this post


Link to post
Share on other sites

My advice would be to copy the htaccess files from a 231 installation.

Share this post


Link to post
Share on other sites

I got 3/4 the way through a more detailed update to this, then the laptop died :(

 

Cruel bots!!!!!

Share this post


Link to post
Share on other sites
7. Add extra login parameter (JanZ) {

2.3.1 and lower

a. link - scroll down to "admin/includes/application_top.php Line 146-151" and start reading.

}

 

probably a stupid question, but what does this do exactly?

Share this post


Link to post
Share on other sites

Isa - helps to ensure that admin log in can only be performed at the login page, and not elsewhere.

Share this post


Link to post
Share on other sites

Gary

 

thanks very much for the info :), thanks also for this useful thread.

Share this post


Link to post
Share on other sites

could I have some advice on what kind of .htaccess file to add to a videos directory?

I thought of using the same .htaccess that's in the images directory, what are your thoughts?

Share this post


Link to post
Share on other sites

Isa - using the same one as is the images fodler would prevent scripts uploaded from being run (which is a good thing to do).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now