Why not to use WordPress with PrestaShop

Today was an exciting support day, if you find things like that exciting. About 30 minutes after getting to the office I received a Skype message from one of our clients. They said their payment gateway stopped working. I logged into their back office and I made my way through their checkout and tried to use my business card to complete a purchase. Nothing happened. I looked at the console and saw an insecure resource blocking the payment request. Strange.

Then I realized…

I opened my ftp client and logged into their site and made my way to the payment gateway plugin, they were using Braintree. I noticed it has been recently edited by the time stamp in the ftp. When I opened the file my heart sank. This is what I opened the file to.

If you cannot tell, this file is taking the credit card information and sending it to an email address after it is submitted to the payment gateway. This is a pretty great hack, I have never seen one pulled off like this before. But they did make a mistake, this morning they had changed something and edited another file. This error had caused everything to break. Which was a gift to be honest, because this hack had been in place several days already without anyone noticing. But also this was a tragedy as well, card numbers had been compromised for several days.

Is PrestaShop in secure?

The short answer is no, it is not. I have never seen a PrestaShop site hacked by hacking PrestaShop itself, neither have any of my colleagues that I asked. But with that being said bad security policies can make any site a target for hacking. WordPress on a server is a bad security policy. It is best to avoid putting it on the same server as your PrestaShop installation.

Let me explain how the hack happened, which in my mind is a total failure on WordPress’s part. WordPress automatically updates to the latest secure version, which seems reasonable, but in all actuality is not and is highly insecure. It does not take into account custom changes or even plugin compatibility, it just updates. What had happened on the server was WordPress tried to update, but failed during the update. It failed while files were being changed moved around. What does that mean? The wp-config.php holds your database settings for WordPress, it was backed up on the server in a text format when I logged on to the server. Basically that would give anyone access to the database on the server if they found the file. Which luckily enough there are scanners that are made specifically to find that file. How convenient. That is where things went down hill and it could have been prevented simply by not having WordPress on the server. Unfortunately with this site it is not possible at this time so we are trying to mitigate it.

How are we mitigating it?

We have put a host of security measures in place on this site to mitigate the issue now. I cannot mention all of them, but let me highlight some of the more important ones we did.

• Changed every password and database name associated with everything
• Installed a security plugin in WordPress
• Disabled FTP and SSH on the server totally
• Scanned the server for vulnerabilities
• Reset file permissions server wide

One thing I did not mention in the list above, because I wanted to go over it more in depth, is we installed a module in PrestaShop to counter act this happening in the future. This module made by El Patron of the PrestaShop forums and owner of etiendas can help alert you to a problem before it becomes a major problem. What this module does is alert you to file changes on your server. Some files will natually change, so you might get some meaningless alerts, no big deal in the sense of security. But if you see changes to modules you have not updated, this module will pay for itself in the first instance. Especially when you consider that the clean up of this server took us around 10 hours not to mention the time the site was offline not accepting orders. it really is a small fee to pay for knowing when something is going wrong. Below is a screenshot of the module in action.

The name of the module is PrestaVault, from a programmers perspective it is a simple idea, but a complex module. A complex module that is useful if you do not want to be on the hook if your shop is hacked. This module can alert you as soon as your shop is hacked so you can start mitigating the problem. You can see in the image above that it scans your server and looks for all files that have been changed. This scan is configurable via a cron job and you can run it as often as you like so you can get alerts as soon as your site is breached. It is something I would highly suggest using. We are actually in talks with them on integrating this module into our support packages for our support clients.

How do we prevent this?

I am glad you asked that, or at least thought it. There is really only one sure fire solution to preventing attacks like this on your shop. Not using WordPress seems like a good solution, but honestly it is not the best. The best solution is that PrestaShop needs to get with the times and realize that sites need a blog. PrestaShop is the only major e-commerce platform that does not integrate a blog in their software. The only. Why? Are they too busy re-designing the back office to give people the features they need? I honestly do not know, but they haven’t made it a priority and it is not in their road map that they have released.

What I propose is to let PrestaShop know that we need a built in blog and hold their fee to the fire. I have a tweet below asking them for a blog in PrestaShop, but they rarely listen to me any more. If enough people re-tweet it they might get the message. Give it a re-tweet, let your voice be heard about how we need a blog and how we need to stop sacrificing security to have a PrestaShop site with good content.