While playing catch up on some of my reading recently, I’ve noticed a number of posts about CRE Loaded admin security. Much of this was prompted by the publication of a PHP_SELF related vulnerability which affected both the admin and catalog pages.
One pretty good article on the topic can be found on the infotales.com blog – http://www.infotales.com/hardening-protecting-cre-loaded-admin-area/. Some good stuff there including inventive use of a security by obscurity method long implicit in osCommerce based code but little used. So far, the post has garnered only one commit – Steve Makin’s note on Sept 1st to the effect that simply leaving the admin out of robots.txt accomplishes the same thing. I tend to disagree.
The only “benefit” to removing the admin folder from the robots.txt file is to allow legitimate bots to attempt to spider the admin space. Make an error in the IP based protection setup recommended in the Infotale article and they will do so. Ostensibly, removing the folder ID from the robots.txt file will prevent it from being published to “bad bots” and reduce exposure. This misses the point that the default admin folder location is ALREADY KNOWN to operators of bots used to locate vulnerable websites and is specifically looked for by any competent cracker of osCommerce based sites. This is reason enough to actually move the admin location if you are looking to gain some security by obscurity for your site.
The Infotale article also suggests that the admin should be secured by .htaccess rules which restrict access to specific IP addresses, require additional passwords for the admin folder and using secure user names and passwords. The first two are great options to use, widely available and in many cases implementable using your hosting control panel. The IP restriction may be tricky to impossible, if your web access relies on a service which does frequent IP switching. The final suggestion , to use secure user names and passwords is probably the most frequently overlooked element of ecommerce security. I’d add to this, USE YOUR USER ID AND PASSWORD ONLY IN SECURED ENVIRONMENTS.
Why? Because the most common form of ecommerce site cracking seen in the pertinent anecdotal evidence has been and remains the social hack. Crackers may be the same service provider who tweaks your code to allow the latest greatest SEO URL’s to be used, entering using the authentication you gave them for purposes very different than what you had in mind. Equally overlooked is the fellow overlooking your shoulder as you type your own authentication on the keyboard at a wireless hotspot or public machine at an Internet Cafe. These types of cracks are great reasons to follow PCI compliance rules related to password changes and strength.
While it would be great if CRE Loaded and other web store software supported the tools needed to implement password rotation and strength policies, you can do this without such tools built into the cart. It requires a bit of extra work, but the results may be well worth it as our experience is that sites hosted in more secure environments and managed using less risky habits tend to outperform other sites by at least 2 to 1. Two tools useful in doing so are PhpMyAdmin and Keepass. Any other password manager will do, and so would any database tool, but PhpMyAdmin is widely available, and Keepass is free. The combination makes them ideal candidates for managing password policies manually when the need exists.
First, know your applications structure well enough to pick out which table to monitor. CRE Loaded uses the admin table to store admin account data, including the ID, password and (most importantly for our purposes) the date field reflecting the last modification of the account record – in this case the admin_modified field. Using PhpMyAdmin – check this table and look for dates which are older than the maximum allowed password age as set by your store policy. When you find them, email the address in the admin_email_address field to remind them it is time to change their password using KeePass or your required password manager using the required settings on the password generator. Don’t forget to recheck to make sure this is done within the required timeframe (2 business days is quite reasonable). Good luck, and good security!
Leave a Reply
You must be logged in to post a comment.