83 replies to this topic

[modelspecialist]

if you change your shop's admin folder make sure you change the link in your browser as well;
say you change your 'admin' folder's name to 'administration'

instead of

http://www.yourwebsitelinkhere.com/catalog/admin/

type

http://www.yourwebsitelinkhere.com/catalog/administration/

to gain acces to the admin panel.
Ofcourse, if you changed the name of the 'catalog' main folder, you should change that name in the link also.

Edited by modelspecialist, 28 May 2011 - 01:39 PM.

[Annisse]

modelspecialist, on 28 May 2011 - 01:35 PM, said:

if you change your shop's admin folder make sure you change the link in your browser as well;
say you change your 'admin' folder's name to 'administration'

instead of

http://www.yourwebsitelinkhere.com/catalog/admin/

type

http://www.yourwebsitelinkhere.com/catalog/administration/

to gain acces to the admin panel.
Ofcourse, if you changed the name of the 'catalog' main folder, you should change that name in the link also.

Thanks, I did that exactly and it doesn't work. Gives me an Error 404 and automatically reverts right back to putting admin/login.php

Edited by Annisse, 28 May 2011 - 02:13 PM.

[Xpajun]

Annisse, on 28 May 2011 - 12:38 PM, said:

Hello there!

Loving all the security contributions and advice! Soaking it up like a wet sponge. Thanks Burt and Xpajun

Now, this is probably an easy answer for you guys but I am in the dark about this.

5. Rename /admin/ and htpasswd it

So I change the admin folder to my new name of choice, then when I go to my Admin page to log into OSCommerce I now get an Error 403. My catalog is still trying to locate the old folder name, admin/login.php

What steps do I also need to do after changing my admin folder name to access my Admin login page again with the new folder name?

Thank you for your help. Total noob with anything having to do with computers and code  

Have you changed the admin name in catalog/your_new_admin_folder/includes/configure.php


  define('HTTP_SERVER', ''); // eg, http://localhost or - https://localhost should not be NULL for productive servers
  define('HTTP_CATALOG_SERVER', '');
  define('HTTPS_CATALOG_SERVER', '');
  define('ENABLE_SSL_CATALOG', 'false'); // secure webserver for catalog module
  define('DIR_FS_DOCUMENT_ROOT', $DOCUMENT_ROOT); // where your pages are located on the server. if $DOCUMENT_ROOT doesnt suit you, replace with your local path. (eg, /usr/local/apache/htdocs)
  define('DIR_WS_ADMIN', '/admin/');
  define('DIR_FS_ADMIN', DIR_FS_DOCUMENT_ROOT . DIR_WS_ADMIN);
  define('DIR_WS_CATALOG', '/catalog/');


change this to the new name of your admin folder

[Annisse]

Xpajun, on 28 May 2011 - 02:29 PM, said:

Have you changed the admin name in catalog/your_new_admin_folder/includes/configure.php


  define('HTTP_SERVER', ''); // eg, http://localhost or - https://localhost should not be NULL for productive servers
  define('HTTP_CATALOG_SERVER', '');
  define('HTTPS_CATALOG_SERVER', '');
  define('ENABLE_SSL_CATALOG', 'false'); // secure webserver for catalog module
  define('DIR_FS_DOCUMENT_ROOT', $DOCUMENT_ROOT); // where your pages are located on the server. if $DOCUMENT_ROOT doesnt suit you, replace with your local path. (eg, /usr/local/apache/htdocs)
  define('DIR_WS_ADMIN', '/admin/');
  define('DIR_FS_ADMIN', DIR_FS_DOCUMENT_ROOT . DIR_WS_ADMIN);
  define('DIR_WS_CATALOG', '/catalog/');


change this to the new name of your admin folder

Really strange. I just tried changing the admin in my configure.php to my new folder name, hit save, and there is an error message -
[a fatal error or timeout occurred while processing this directive]

it won't allow me to change it.

Could this be because of some of the security contributions I just installed?

Edited by Annisse, 28 May 2011 - 03:22 PM.

[Annisse]

OK got the the admin/includes/configure.php file all updated with my new admin folder name.

I had to delete it out completely. Get the configure.php file off my computer to edit it with my new admin name. Then reupload it again to work.

and from reading another user's post it was two lines I had to edit...

define('DIR_WS_ADMIN', '/changedadmin/');
define('DIR_FS_ADMIN', '/home/content/html/changedadmin/');

Thanks for your help! I am on my way to be hacker free!!! I hope!  

have a great weekend all!!!

[DunWeb]

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

[burt]

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

[Taipo]

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.

[Juto]

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

Sara

[Juto]

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

[Juto]

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

[Taipo]

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

[burt]

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, 02 June 2011 - 11:06 AM.

[shawaj]

burt, on 16 May 2011 - 11:45 AM, said:

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

[Juto]

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

[Juto]

Hi! I have just installed r6 and in
  // Preset other variables

I  added:
  $hasHexvars = False;


Now, all warnings are gone

Sara

[shawaj]

anyone able to answer my question above?

thanks

[Taipo]

shawaj, on 03 June 2011 - 09:27 PM, said:

.....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

[Taipo]

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]

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!