OsCommerce Being Hacked?

[tcr1016]

I am looking at using OsCommerce for my business. But I hear that many sites have been hacked that use OsCommerce. Is this only because the hacker was able to get into the sites server??? Or is it due to the hacker getting in through OsCommerce?? I am concerned since my store will offer downloaded pdf s only. I will be selling other people's ebooks and do not want a hacker getting in. My server access user and pass are encrypted. So how safe is OsCommerce for download only items??

 

Thank You

[Velveeta]

I am looking at using OsCommerce for my business. But I hear that many sites have been hacked that use OsCommerce. Is this only because the hacker was able to get into the sites server??? Or is it due to the hacker getting in through OsCommerce?? I am concerned since my store will offer downloaded pdf s only. I will be selling other people's ebooks and do not want a hacker getting in. My server access user and pass are encrypted. So how safe is OsCommerce for download only items??

 

Thank You

This is a very broad generalization to be making... I'm sure there are plenty of sites running osCommerce that have been hacked... However, the question is really how many of those sites were hacked because of a vulnerability in osCommerce, and how many were hacked because of 3rd party code? There are over 5000 user-contributed contributions available for adding features to osc, and not all of them are written well... in some cases, people may have installed code that allowed for a sql injection attack to be used against them... in other cases, maybe something else... since you're specifically asking about e-products that are download-only, it's going to depend mostly on your a) server security, to prevent someone getting into the server itself to download those files manually, and B) web directory security... Some people that have had issues with downloadable products in the past may not have had their files plundered by any fault of osc, but rather by bad directory permissions that allowed someone to access their download directory directly, and just click down a list of hyperlinks to download everything they had...

 

There's no such thing as bug-free software... Even something as simple as a 'hello world' program is dependent upon the library code of the underlying language it's using, etc... the best advice I could give would be that if you decide to go with osc, harden your system as much as you can, don't leave it up to the out-of-the-box code to do it for you or be a catch-all system, although it is pretty good at what it does.

[♥geoffreywalton]

Spooks has 4 contributions that will help ensure your site is secure.

[Guest]

it's not oscommerce being hacked, it is usually unpatched oscommerce shops that get hacked. (store owners that don't keep up with the latest security patches or those who don't do the basics, such as locking down the admin panel .. or those that keep their folders chmod at 777.)

 

no open source program is usually totally "secure" out of the box. there's always steps you need to implement to keep it safe.

 

you'll run into this issue regardless of what shopping cart software you choose.

[tcr1016]

it's not oscommerce being hacked, it is usually unpatched oscommerce shops that get hacked. (store owners that don't keep up with the latest security patches or those who don't do the basics, such as locking down the admin panel .. or those that keep their folders chmod at 777.)

 

no open source program is usually totally "secure" out of the box. there's always steps you need to implement to keep it safe.

 

you'll run into this issue regardless of what shopping cart software you choose.

 

Where do I find the security patches??? And locking down the admin??? I do know not to keep the cdmod at 777.

 

Thank you for all your help.

[Guest]

patches are released in the news and announcements section of the form (rc2 is the latest fix): http://www.oscommerce.com/forums/index.php?showtopic=289553

 

rename "admin" to something else, that nobody could ever guess.

rc2 has a admin login screen built into it.

for additional layers of security, you can .htaccess password to it (if you have cpanel, you can do it right from the cpanel admin screen)

also, via htaccess, i limit access to my admin folder to my ip exclusively.

 

other security-related topics:

What to do BEFORE you get hacked

Here's a little trick to protect your admin folder

How to secure your site

 

the security pro contribution by fwr media is a MUST!

[kbking]

.. or those that keep their folders chmod at 777.)

 

There is a popular contribution called 'On the Fly' Auto Thumbnailer using GD Library which does a very good job, but according to the instructions it requires the images folder to be chmod at 777 in order to function. A lot of osCommerce-sites are using this particular contribution. Are they all at risk?

[germ]

If you have your images folder (or any other web accessible folder) at 777 it's just a matter of time until you get hacked.

 

The only questions are "When?" and "How bad will it be?"

:o

[Guest]

There is a popular contribution called 'On the Fly' Auto Thumbnailer using GD Library which does a very good job, but according to the instructions it requires the images folder to be chmod at 777 in order to function. A lot of osCommerce-sites are using this particular contribution. Are they all at risk?

i use that contribution and my images folder is set at 755, works perfectly fine. i can upload images via the admin panel without an issue.

[kbking]

i use that contribution and my images folder is set at 755, works perfectly fine. i can upload images via the admin panel without an issue.

Thanks both of you for your answer! I'll check if the same setting will work for me.

[MrPhil]

A lot of people, including an unfortunate number of contribution developers, think that a directory has to be 777 to be writable by the application, or even that all directories should be 777. This is sheer stupidity. If the first thing someone tells you is "chmod all your directories to 777", they're an idiot and you shouldn't listen to them. This is especially true on shared servers (with other people's web sites), not as important on a dedicated (just you) server.

 

Directories should always start out as permission 755. If the server (Apache) and PHP are running as "owner" (e.g., running suPHP), the application should be able to write to any directory. You can change a directory to 555 if you want, to prevent any new files from being written into it, but you'll need to change it back to 755 before doing any work in it. Now, on some systems, PHP and/or Apache are configured to run as "group". If they need to write to a particular directory, its permissions will have to be 775. That does not mean that all directories should be changed to 775 -- just those that osC complains are not writable. On some systems, PHP and/or Apache run as "other" or "world". They would need for a directory to be at 777 in order to write to it. Again, not every directory -- just those that osC needs to write to. If your system is running suPHP security software, 777 (world writable) permissions will cause a 500 error.

 

Shell scripts, Perl scripts, and binary executables should also be 755 if they contain a "shebang" line 1 (#!/path-to-processor), but only advanced users might encounter those in osC. Some systems may require PHP files to be 755 -- you'll certain find out soon enough! Ordinary files should always start out as permission 644. If the server (Apache) and PHP are running as "owner" (e.g., running suPHP), the application should be able to write to any file. You can change a file to 444 if you want, to prevent any changes to it (make it Read-Only). Configure.php requires this, to reduce the chance of accidental or malicious changes to your configuration. It can be done to any other file, but just remember it means extra work when you need to edit or upload a new version of the file -- you first have to change permissions back to Read-Write for you (644). Now, on some systems, PHP and/or Apache are configured to run as "group". If they need to write to a particular file, its permissions will have to be 664. That does not mean that all files should be changed to 664 -- just those that osC complains are not writable. On some systems, PHP and/or Apache run as "other" or "world". They would need for a file to be at 666 in order to write to it. Again, not every file -- just those that osC needs to write to. If your system is running suPHP security software, 666 (world writable) permissions will cause a 500 error.

 

In general, stay with the most restrictive (no write access) permissions for "group" and "other" (755 and 644). Only if osC reports that it is unable to write to a specific directory or file, should you grant more generous permissions (write access) to groups or (as a last resort) other/world users. If you know that you need to grant write access to one directory or file, and you know that certain other directories or files are in the same situation, you can go ahead and change others at the same time. Just don't go and do every directory and file.