https://www.youtube.com/watch?v=sdPDcXA50Sk

A lot of store owners and even many WordPress developers assume that an SSL certificate is all it takes to secure your WordPress site for e-commerce. The interesting thing is that an SSL certificate doesn’t actually secure a server at all. An SSL certificate simply encrypts the communication between the web browser and the server the browser is talking to. Let’s take a look at the role of SSL certificates in the context of PCI compliance.

When you secure your server for e-commerce, there are a bunch of things that need to be considered. First, you have to meet the bare minimum requirements as specified by the Self Assessment Questionnaire you are filling out. Depending on how you are processing credit card payments, this “bare minimum” isn’t actually so “bare” after all. In fact, if you are not using a secure hosted payment page like you get with Cart66, the reality is that you need to use the SAQ A-EP which is about 50 pages long and has over 130 different controls and requirements to meet. So, as you can see, simply installing an SSL certificate doesn’t get you to where you need to be.

SSL Certificates Don’t Secure Servers

Keep in mind that an SSL certificate doesn’t actually secure your server at all. The only thing an SSL certificate does is encrypt the communication between the web browser and the server that the browser is talking to. It doesn’t do anything for actually securing the data on your server or the access to your server.  To put it another way, an SSL certificate is not a firewall. SSL certificates do not block or filter malicious traffic. It doesn’t prevent SQL injection attacks. It doesn’t make WordPress more secure. It doesn’t prevent hackers from modifying files on your site. The only thing it does is encrypt the data sent to your server from the web browser when a form gets submitted. This is not to say that SSL certificates are not valuable because they are. It is important to provide secure communication between the browser and the server. Otherwise the communication could be intercepted and read which could reveal things like passwords you are using to log into your account on a web site.

What Can Go Wrong?

Lots of things can potentially go wrong that would allow bad things to happen. Here are just a few examples.

Known vulnerabilities: During the life of virtually all software, security vulnerabilities get discovered and the software developers release patches and updates to fix these problems. Once the software has been updated it is often made know what the vulnerabilities were that got fixed. The problem is, if you didn’t upgrade to the latest version of the software, there are known ways to cause security problems with your site. Hackers can (and do) read change logs and other reports to discover the security holes in popular software. Then they look for sites running the older versions of the software that haven’t been patched yet. This is why one of the requirements for PCI compliance is:

Are critical security patches installed within one month of release?

Known vulnerabilities can exist in software running on your server, such as your web server software, your database, your mail server… anything. Another prime candidate are the WordPress plugins you are using. Often times plugins are written be developers who don’t have as much experience as the core WordPress developers and, therefore, accidentally introduce major security holes into your website.

Insecure communication channels: There are many ways to connect to a server. One insecure way if over FTP. In fact, if you have FTP enabled on your server it is not PCI compliant. FTP is considered to be an insecure communication channel because usernames and passwords are passed over the network in plain text. That means anybody can look at the data being transferred and see your username and password. It’s generally a bad idea to use FTP for anything, especially now that there are much better modes of communication such as SFTP or SSH.

SQL Injection Attacks: This is a type of attack where the hacker sends some data in to your server – perhaps by simply submitting a form – and the data received ends up injecting code that your database will run. Suppose your site has a database query to find a username when given an email address and the query is written like this:

SELECT username
FROM users
WHERE email = '$email_address'

This may look like a fine query at first, but what if the value of $email_address actually contains some code rather than an actual email address. For example, suppose the value of $email_address was something like test@test.com' OR 'a'='a

When the server evaluates this code it will see this query:

SELECT username
FROM users
WHERE email = 'test@test.com' OR 'a'='a'

Since a always equals a this query will return a list of all the usernames in the database. This is just a mild example. It doesn’t take much creativity to see how this technique could be used to reveal all sorts of data or even to delete or change data in your system.

They’re In. Now What?

Once a hacker finds a hole, they don’t have to do much to cause a huge problem for your e-commerce site. Whether you are using an iFrame, a Direct Post, or JavaScript to collect and pass credit card data to your payment gateway, all of those techniques can be foiled by a tiny snippet of bogus JavaScript. Suppose a hacker finds a way to inject a tiny snippet of JavaScript into your site. That JavaScript can change where you are sending your credit card data. Worst of all, this change can happen without any visual indication that there is a problem. Everything will still look exactly like it normally does and you will even still have the SSL lock suggesting the page is still “secure.”

This is why SSL certificates can be so misleading. As far as the SSL certificate is concerned, it’s still doing everything it was supposed to do. All of the communication between the web browser and your web site is still encrypted and “secure.” The problem is that doesn’t make any difference because your website is now sending the credit card data (that was transmitted securely) off to the bad guys.

How To Fix The Problem

There are two ways to address this problem. One way is to put a lot of effort into making sure your server is (and stays) secure. This will involve all sorts of security scans, firewalls, and many other security measures that you can read about in the PCI Compliance document library.

The other way to fix this problem is to have a professional service handle the credit card payment process for you. For example, you could use a service like PayPal where your customers are sent to the PayPal website to pay for the order. Of course, we all know that only offering PayPal is not an ideal way to run your online store. PayPal is a nice alternative to offer people who already have PayPal accounts, but it is clearly best offered as an alternative payment method, not as the primary way for your customers to pay you.

Cart66 provides a secure hosted payment page that looks exactly like the rest of your WordPress theme because we use your WordPress theme to skin you hosted payment page. It looks EXACTLY like all of the other pages on your WordPress site because it is literally using the same code, just imported and secured on your own slice of our PCI compliant Cart66 Cloud servers.

With your Cart66 hosted payment page, you get the best of both worlds. You get all the security you need for running a safe and secure online store without giving up any of the things you would normally have to sacrifice if you wanted to use a 3rd party hosted payment page. Since Cart66 skins your hosted payment page with your WordPress theme, you don’t have to give up your branding and design and your customers won’t feel confused like they are bopping between unrelated website during the checkout process.

If you are interested in more details, check out this video / article showing how your Cart66 hosted payment page works.