Zen Cart has released a patch for all versions v1.2 through v1.3.7 that fixes a serious security hole in the admin login/password reset system.

I strongly advise all current ZenCart users to see to it that this patch is performed on their systems. The patch takes less than fifteen minutes to complete.

If you need help with this patch, I can install for $25.

Contact me below for details.
[CONTACT-FORM]

I have written several times about debugging a live site and posted snippets for working on the themes of a live WordPress install. One trick I haven’t mentioned is using the PHP error log.

PHP on any production site should be configured to not display errors. I see all too often on random sites that PHP has been configured to show errors (sometimes even in Google results). This gives away too much information about your application and server.

On the servers and applications I work on all of the time, I configure PHP to log errors to /var/log/php_errors. Simply tailing this file through a console will quickly show any errors caused by the edits.

To enable logging, check these two variables in your php.ini:

To tail the log file from an SSH console:

These are all useful when trying to track down an open formmail script.

List bounce messages

Freeze bounce messages

Freeze messages from user@domain.com

Find out what user your webserver runs as. Use this as the email address to key on. For example, my Apache runs as nobody so I want to freeze all messages sent from the user nobody@domain.com so I can look through them to see if I can deduce where the insecure formmail script is.

Delete frozen messages

Credit card slamming is the practice of trying hundreds or thousands of card numbers and security code combinations to find the few in the batch that will actually work. I have discussed credit card slamming here and over at the ZenCart forums several times in the past.

The code snippet below can be used in modules/checkout_process.php to automatically log a user out after a set number (6 in the below snippet) of payment attempts.

Place in between this code near the top of the file:

I found six attempts to work well on the sites I implemented on. You do not want to adversely impact normal users but you do want to make it harder on abusers so that they just go away.

BE WARNED

Improper use of this code could prevent anyone from checking out. The two things that will save you when trying this out are:

1. MAKE A BACKUP
2. FULLY TEST BEFORE CALLING IT COMPLETE

Nolisting – Poor Man’s Greylisting

I thought this was an interesting option to try to weed out some spam on servers inundated by spam. It wouldn’t be a permanent fix as it would only require a trivial workaround. But in my experience, these types are lazy and will go off to easier pickens if they run into too many problems.

Update

I bookmarked this site late last week, but wasn’t able to connect just now. If the site doesn’t come back shortly I’ll post a link or two to other sites discussing. Or if I can find the time, post my own implementation.

I have a major client whose Authorize.net gateway account gets hit sometimes hundreds of times a day with charge attempts. Most are posted by an automated script from IPs coming out of Indonesia or Eastern Europe in an attempt to find a valid credit card number and security code. Fortunately, it hasn’t cost the client any money directly yet. Out of the thousands of attempts in the last few months only a couple of charges actually captured funds from the stolen card information. All of these were promptly cancelled after review.

In discussions with this client, we came up with the following options. They are listed in order of ease to implement and least impact on legitimate customers.

1. Require only a billing address and plainly state all orders are only shipped to billing address
2. Require card billing address and shipping address to be in same country or deny the order before going to authorize
3. Require all international orders to be Paypal so they can’t automate the whole process (or maybe allow orders from countries with low fraud percentage to use a credit card directly and all others Paypal)
4. Automatically log user out after X failed attempts
5. Automatically block the IP address after X failed attempts for a time period between a few hours to a day or two
6. Match customer’s IP address to billing / shipping country before going to authorize

My thinking is the better methods would include ways of slowing down the requests so that automated script kiddie tools would constantly fail while legitimate users that are just having problems would not be completely prevented from checking out. I also think a more robust system would utilize several layers of protection (same as a multi-layered approach to server security is better in the long run than putting all of your eggs in the single proverbial basket).

Over the course of the next few weeks I will implement some of these options and dream up more if necessary. Stay tuned for updates.

Should your site be experiencing similar issues, contact me to discuss options.

Note

Maxmind supplies a free IP to country database in CSV format along with their commercial IP database products.

The MySQL client allows specifying the database password on the command line using the following parameters:

If you are in a habit of doing this… STOP NOW!

If you are using a shell like Bash, the password is saved in the bash_history file. Should anyone into the server, they can easily get your MySQL password by viewing the history file.

Altering the command line to:

Causes MySQL to ask for the password, so that it cannot be stored in the history.

Proper security is layered. Just because one account password is hacked, doesn’t mean you should give away the keys to MySQL too!

Spammers have now moved from email spam to blog comment spam to forum spam. I have received several complaints of dozens of daily messages posted to public forums. One enterprising spammer has been posting advertisement for his forum spamming services with links to an email address for contacting him.

If you have a low volume forum, you can subscribe to all new posts and delete as necessary. Most spams that I have seen come from a new user account. The spammer appears to be using a script to create a new forum account to post the single message and move on. Subsequent spam messages are also posted from a single use forum account. One way around this is to require admin approval on all new signups. Another option may be to require captcha and or email validation before automatically approving the new forum account. YMMV as some captcha systems can be easily circumvented.

Good security consists of multiple layers of procedures and applications, all with the goal of keeping unauthorized users out and ensuring properly authorized users have access to only the things they should. With public internet servers and web applications this can mean things such as:

• Ensuring users create at least moderately secure passwords
• Instituting mandatory password changes on a monthly or quarterly schedule
• Regular security audits
• Firewall and firewall maintenance

Another layer not usually thought of is obscurity. If they can’t find it, they can’t exploit it. That being said, obscurity by itself isn’t very secure. It only takes one malicious user to find what has been hidden and all hell breaks loose. Multiple layers of security build upon each other more than just through addition. They add orders of magnitude more security to the system as a whole.

Most web applications support changing the default install directories. To keep prying eyes out of your data, move PHPMyAdmin into a directory with a random name. Move the admin directory for an applications like, ZenCart. If you are use these admin URLs frequently, the URL will be saved in the history of your browser and always accessible. If not a simple bookmark can help you remember.