Having your site hacked is a PITA. It can be far worse if you weren't prepared…

Step One: preparing to recover from an attack

First off, store an entire set of working files locally. This should be a set of files that has never been off your computer so that you know that they have not been tampered with. Edit them locally, when you need to, and then upload them to your webspace, either through the file manager in your cpanel or with ftp, sftp, ssh, or something similar. You don't have to upload the entire set each time, just the modified files.

Some people edit their files live on the server. If you do this you will not have a current local copy. If you download the file(s) from your server, you do not know for certain that they have not been modified by a hacker. ALWAYS edit your local files and upload them to the server, not the other way around.

It wouldn't be a bad idea to get XAMPP (from Apache Friends) and develop locally, or use the osCBooks "localhost" package which can be found here.

Before installing a new contribution, make a copy of the entire local directory and datestamp it (rename the directory copy to indicate the date). That way if anything goes wrong, you can revert to the old copy. It is a good idea to keep a couple of these snapshots (backups taken at different times) around just to be safe.

Now, if your site ever gets hacked it is easy to fix. Go to your webspace and delete all the files associated with your site. Use some common sense though. There may be other folders such as for cgi, logs, statistics, etc that you might want to keep. (They should not be in a web accessible location anyway but that's another issue).

Once you have deleted your website from the server, upload the entire fileset from your local computer. Now, your website should be back to where it was before you got hacked. That should be a fairly quick and painless recovery process – certainly this can be done in minutes if done correctly.

Do not upload your files over the existing files. You must delete everything first. Otherwise you will not remove any new files or folders that were added by the hacker.

Step Two: protecting against an attack in the first place

Most important…set the permissions correctly! The documentation states that you should set the permissions on a few folders to 777. That is fine if you want to be hacked. If you follow those instructions, you WILL be hacked, it's just a matter of time.

Set the permissions on ALL folders to 755. If your host has PHP installed as CGI through suExec (the proper method), then your site will run fine this way. If they have PHP installed as a module, you will get a warning from oscommerce saying that it is unable to write to the images folder. Setting permissions back to 777 will make the message go away but it will leave you open to an attack. Contact your host and ask them if they could change the way in which they install PHP. If they will not, you should immediately get a new host. This isn't an arbitrary statement. By installing PHP the wrong way, they have created a security vulnerability that you will not be unable to resolve. A partial work-around is to upload images via file manager in cpanel or through ftp. A less secure method is to set the permissions on the images folder to 777 just long enough to add your new products and then set it back to 755. This work-around does not, however, deal with the permissions issues on a couple of other folders. Loading PHP in the correct manner is the only fix.

Set the permissions on all files to 644, with two exceptions. There are two configure.php files. One is located in /catalog/includes/ the other is in /catalog/admin/includes/. The permissions on these two files should be 400, 444, or 644 dependent on your server configuration. Use the lowest setting that will still allow your store to function and that your host's setup allows you to set.

If you have trouble setting permissions on files or folders through ftp, try the file manager in cpanel instead. Some hosts don't allow ftp to change permissions.

The admin folder requires a password (in the latest version of osc). This method of password protection is not secure. A hacker could run a password cracker program against it and try thousands of passwords a second until they get in. Use the feature in cpanel to ALSO password protect your admin directory. When a hacker runs a password cracker program against this, the system will be notified after a set number of attempts and the hacker's IP will be automatically banned from the system (on a properly configured server. It wouldn't hurt to check this with your host).

Renaming your admin folder to something obscure (a 12+ character long string of random letters and numbers would be best) makes it even more difficult for hackers since they won't even know where your admin folder is now. You will have to modify your configure.php files to point to the newly renamed admin directory. Be sure that you do not list the new name in any other files (like robots.txt) as this will give the name away.#

Step Three: further securing your shop

Install the following security mods:

Security Pro
Sitemonitor
IP Trap
.htaccess Protection
Anti-XSS

With all of those changes made, it is unlikely that you will be hacked. There are always other methods of attack and some can only be prevented by making changes to the server configuration (which is out of your control). Keep in mind that shared-host accounts have more security issues than dedicated accounts and that "cheap" accounts are just that; don't expect that a cheap account is managed by competent or conscientious people.

Lastly, make sure that your admin settings for file-based sessions and cache (if you use either), do not use the /tmp folder if you are on a shared-host account. On most systems, the /tmp folder is a symlink to a shared system folder that all the other accounts on that shared-host also use. Not only can this potentially cause problems but it can be a security leak, sharing customer data through this shared folder

This post was taken from the osCommerce forum – and was made by php_Guy. There aren't many posts that I would take from there and post here as much of the official forum is "noise". Nice work php_Guy.