OK, so maybe we need to start with the basics on this one. With these days of paranoia over being hacked in one way or another you would think the obvious things would be covered by most people, but only today I found another longstanding live osCommerce store that didn't even have it's admin password protected in any way. This store owner must have been lucky up until now, but the law of averages states that sooner or later someone more dubious than myself would have come along and take advantage of this fact.

But what is the interest of an open admin for a hacker anyway? Surely, if you don't store credit card information in your database, there is little of use to them, other than just causing upset by deleting/changing things and generally messing about with the smooth running of your osCommerce store?

These kinds of attacks are of course quite obvious to both the store owner and their customers, and are relatively quickly noticed and corrected. What is more concerning are the steathier attacks that take place. Once such serious of "attacks" I witnessed involved a store where credit card details were not taken on the site; instead a payment processor was used for this purpose. However, the credit card module was being mysteriously enabled "all by itself" and orders were being deleted as soon as they had been placed. Eventually, this was found to be due to an duplicate, unprotected admin installation which had been forgotten about, which the attacker was using to enable credit card payments and then note the customers details before the store owner knew anything about it.

So, how should you go about protecting your osCommerce admin? There are a couple of ways to do it.

Directory Protection - if you are using something like cPanel, Ensim or Plesk, then you should find this feature in your hosting adminstration panel. It will cause a pop-up dialog to be displayed in your browser whenever you try and access the admin folder or any folder below it. The good thing about this kind of protection is that it is controlled by the webserver directly and therefore it is difficult to hack to gain access to the password.

This disadvantages are that it is difficult to know if someone has been repeatedly trying to access you admin by guessing your password (without checking your webserver access log) and an attacker can have an indefinitely number of tries at this.

Therefore, as with all password protection methods you should choose a password that is difficult to guess/crack, with a reasonable number of characters and avoiding words found in a dictionary. "5@yf6*we" is a good password "password" is not!

Administration Contributions - Another method to use is to implement one of the admin contributions, such as Admin with Access levels. This provides session based access control through php/mysql.

With such a solution, better auditing and hack protections can be implemented, although these are not always used. Locking down the system down so that logins can only be made from a particular IP address and sending notifications of failed login attempts to the administrator all help to protect your system and maintain awareness of what's going on.

The rule of choosing a strong password still applies with this solution, but also you should choose a password that is unique for this purpose. You should never use the same password for your database access, osCommerce admin, or cPanel login. This can mean the difference between a relatively minor compromise or a major incident.

To illustrate the point, I have seen unsecure servers where it has been possible to view the configuration files for php driven sites in other accounts. By looking for the username and password used for the database connection it has then been possible to login to the cPanel account for that user because the details were the same. In this situation it only takes a matter of seconds before an attacker can do anything on your webhosting account that you can.

It is worth remembering that such protections discussed above are not in themselves infallible. I have seen cases where a server had been compromised through an account other than the one on which the target osCommerce site resided. Through poor configuration of the server, the attacker was then able to access the webspace of any account on the server and edit files where permissions allowed. The admin login.php file for the target osCommerce site, which used an adminstrator contribution had been altered by the attacker so that the password e-mailed to him whenever the administrator logged in, thereby granting him access to the admin interface directly. Note that if directory protection had been used, it might also have been possible for the attacker to remove this protection if the permissions on the .htaccess file were not set correctly. There are ways to avoid such problems and also to check the basic security of the server on which your site is hosted - these I will cover in a future article in which I will show you some common hackers tools which you can use to check this for yourself.