Diving into eCommerce 3rd-Party Integrations and Payment Gateways with Dre Armeda and Lee Blue
WP eCommerce Show

 
 
00:00 / 58:23
 
1X

Today, we are doing Episode 38 and the fourth and final in our eCommerce & Security Series. We talk with Dre Armeda, co-founder of Sucuri.net, the sponsor for this series, and Lee Blue of Cart66.com.

Today we are lucky to have this powerful duo take us into 3rd-party integrations and payment gateways. We explore tips and insights to ensure that all of your customers’ data is secure and that your site can safely handle this information without you having to be concerned about compromises.  This is a must-listen-to show for anyone who runs an online store, as well as people or agencies that build and support WordPress eCommerce sites.

We chatted about:

  • The eCommerce site data beyond credit card numbers that need to be protected and why
  • What an SSL certificate is and its role in eCommerce security
  • The differences between accepting PayPal and accepting credit card payments from a security and PCI compliance perspective
  • The types of products that can affect how you choose to process the payments on your site
  • Which eCommerce features have the biggest impact on security
  • Some tools to help shops owners in terms of overall eCommerce security

Thanks to Our Podcast Sponsor: Sucuri.net

Transcript

Bob Dunn: Hey everyone, and welcome to our show. Bob Dunn here, also known as BobWP on the web. Today is episode 38, the fourth and final show of our four-part series on security and eCommerce. Today we are rounding out the series on the topic of third party integrations and payment gateways. Like the other three shows, this is a huge area. We’re going to make our best attempt to give you a birdseye view, but also enough details to really help you with your online store.

To do this, we are bringing in the heavy hitters, who are going to drop those knowledge bombs and round off this series with even more information to help you with the security of your online store. First we bring back Dre Armeda from our sponsor, Sucuri.net, who has guided us through these last three episodes and has been nothing but an excellent sport in spending this much time with me. Hey Dre, are you ready for this last one?

Dre Armeda: Well, not after you told me I got to drop some knowledge bombs. I’m a little nervous now, but we’re here.

Bob Dunn: Well, you’ve done a few already, so, I think you’re on a roll. What I’m going to ask Dre to give us a bit of a quick recap of the last three shows, and then I want him to introduce our second guest.

Our Last Three Security-focused Shows

Dre Armeda: Aw, snap, so we got a guest. This is going to get pretty awesome. I’m excited. Bob, thanks for having me again. We’re certainly glad to be a part of this. I think this is a really good value add to any of your listeners and folks out there. We’ve covered some pretty strong topics as it comes to security with eCommerce and so on.

Episode One: Website Security Threats

Bob, we started out a few weeks ago talking about today’s website security threats. I think that was a great standing ground point to really kick this off, give people an idea of some of the things that they are inherently dealing with when they are online. I introduced the notion of reflective attacks, which I think is super important to understand because they are on the rise. I used the example of hacking, say, a website through their DNS, so maybe redirecting a site, malvertising, if you will, without even having to penetrate the actual website defenses. Going out through a third party service that needs, that’s integral to keeping the site up, attacking that, taking it down, availability is gone. That’s a big issue that we’re seeing on the rise.

Attackers are targeting not just a website’s audience these days, but they’re really starting to focus on targeting the website owner and their infrastructure. Now this, these top ten lists that we’ve been talking about, and hey, it’s securing your application passwords and all that fun stuff that’s a part of it, but we need to think bigger than that holistically, because the attacks are growing well beyond, let’s say, WordPress.

We talked about the notion that website security is not static, and it is bigger than WordPress or any other application out there. It’s about the entire stack, and that goes back to those targeted attacks that we’re seeing. It’s your environment, your hosting, how you’re managing your site, and the processes you use or employ to manage that site and administer. It’s about the people involved and how they use those processes and technology. Again, that whole theory about people, process, and technology, it’s a big deal. We need to consider all three of those pieces to make this work.

Your cupcake website is as susceptible to attack as those other websites out there that are getting a million visits a day, not to say that your cupcake website isn’t, but if it is, we should talk about some investment opportunities.

Most attacks, we got to consider, are not opportunistic, or they are opportunistic. They are … Targeted attacks, are not something that you see as a high percentage. Automation, opportunistic, you’re not the FBI. Typically those large attacks that are targeted are for specific political reasons, monetary gain, things of that, but most of the time, I’d say 95% of attacks that you see out there are automated and opportunistic. You’re online, they’re going to attack as many people as you can. You’ve seen all this crazy stuff with the internet, of all things, I mean, your video cameras at home to your dishwasher that’s connected to the internet. It’s online, if it can be attacked, it will be attacked.

I also briefed them a little bit on defensive depth. A layered security approach is always the way to go. An application alone, an application based utility alone cannot give you the level of protection you need, being it’s already in the environment. It’s as an extension of your CMS, right? It doesn’t load anything before your environment. Availability attacks inundate environments and server resources, and once they’re on the server, it’s a little bit too late, so you got to consider that. Add a cloud based protective layer to mitigate things like DDoS. A layered approach using those application based utilities, external perimeter defenses, that’s really what’s going to give you the best risk reduction capabilities.

We talked a bit about backups and passwords, right? Those are still a thing. I can’t believe we’re still talking about passwords at the end of 2016, but we are. Backups in the event of catastrophic failure, which happens. If you don’t have backups and your server’s blown away from some type of attack, there’s no way to really recover. Having backups and backups of your backups all over the place makes it really easy for you to get back online, minimizing the downtime. Passwords, geez, we’re not even going to get into that. Just don’t use password as password, that’s crazy, okay?

Episode two: payment data stealing and your host’s role

In episode two, we talked a bit more about the basic concepts of website and eCommerce security, so a bit more beyond just what kind of basic attacks are happening. Bob, do you remember what the holy grail of eCommerce is? It’s the sensitive information. We talked about PII, personal identifiable data. We talked about PAN, which, primary account numbers and information.

Vulnerabilities in eCommerce are quite similar to what you’re seeing in blogs and marketing sites, these [brochureware 00:06:08] sites. They’re finding penetration points. They’re automating these attacks. The big difference for attackers in attacking eCommerce is the motivation. Their motivation is that data. That data is super valuable, not just to us and our customers, but also to attackers, because they can sell it for big cash. Data exfiltration, that is where we’re working here, what we’re working with here. This type of sensitive information breach is pretty significant.

Payment data stealing leads to payment card companies really being aware of what’s going on here, and they actually got together and started a standard to get this moving and try to minimize these risks for commerce, for merchants, for consumers, alike. That’s where the payment card industry data security standards were born. PCI DSS, big deal. We talked about it in depth last week. This standard was developed in collaboration with Visa, MasterCard, American Express, Discover, and JCB, with the hopes of combating general online distrust with online commerce. It’s a big deal, man. There’s a lot of credit card transactions happening every day online, and we need to do our best to safeguard this stuff, and the credit card organizations feel the same way.

In episode two, Bob, we also talked about tips for looking for a host. A hosting provider is kind of a big deal too, right? This is where all of your stuff’s going to be housed. These are where all of your transactions are going to be made, and this is where you’re going to make your money. Asking the right questions is super important from the beginning.

I finally broke down and gave you a list, which you know how much I love/hate a list, but I did it anyways, nonetheless. Some quick tips came from it, though, which was pretty cool, including what I think is the most important, expectation management. You need to be on the same page with your hosting provider. Don’t assume. Make sure you understand everything you’re getting, and what you’re not. For example, what type of PCI compliance are you dealing with with that hosting provider? Are they going to provide the adequate level of compliance that you need for the type of business that you have and the type of commerce and payment card processing you are going to be doing. Who’s responsible for cleaning up application level security exploitations? If you get attacked and owned, all of a sudden you’re serving Viagra ads, is it up to you to clean or is it up to them? What are the response times and what have they done in recent breaches? How have they handled that? At the end of the day, cheap does not mean secure. That’s what I want you to take away from that, and don’t leave anything to chance. Don’t make assumptions.

We then talked about content delivery networks and web application firewalls. That was a pretty cool discussion, I think an important one, again, as you start to think about layered security. I say do it. CDNs will give you the ability in some cases to improve your site performance by 50%. That’s pretty awesome, right? Two to three times faster, in some cases, depending on the platform that you’re using and how it’s configured. The clearest advantage, I think, beyond performance is security. That’s really where you need to be focusing. I think security and performance as a dual thing is important.

I recommended finding a web application firewall to help protect against attacks at the edge, the perimeter, again, layered defense, but also find one with content distribution network capabilities. This helps from a security standpoint and performance. Lot of cashing mechanisms built into these environments, so in the event that you are hit, maybe you minimize outage time there. That’s a good thing.

The last kind of, and I think really important one to me, that we talked about in episode two, Bob, was the FUD factor. All this, there’s a lot of misinformation out there, and it can lead website owners to a false sense of security. Also a false sense of insecurity, and what I mean by that is maybe they’re doing the right things and this FUD leads them to make decisions that actually weakens their security stance. That’s a problem. It’s all done for marketing and sales versus taking a, “Hey let’s educate people and get more secure online.” That’s a bunch of crud, it’s a bunch of fraud, I can’t stand it, so watch out for snake oil products out there with blaring sirens and all these flags telling you something’s wrong when maybe it’s not. Those alerts are a little crazy and sometimes it’s nothing there. Sometimes they don’t even alert when things are happening, and that’s the problem.

Remember that a plugin alone can’t completely protect you. Think defense in depth. Again, layered security. You’ve heard me say it like eight times, now. Do your research. Read reviews and ask the hard questions, and always, always, layer your defenses.

Episode three: the importance of Payment Card Industry (PCI) compliance

Lastly Bob, and again, something that we talked about in depth last week was PCI. It’s already covered on here again, and I suggest to any listener that’s on for episode four, that you go back and listen to episode three. It was pretty neat. We talked all sorts of cool stuff around using the standard, and really minimizing risk for you and your client, so cue up episode three. I briefed PCI, also a few minutes ago, and it’s important, it’s an important standard and it applies to all commerce. If you’re processing credit cards, in any capacity on your site, you need to be aware of this. Again, different levels, but it still applies.

I think the most important thing you need to do as a merchant is protect your customer data, whether it’s personal or account data, it’s valuable to you, your customers, and attackers. PCI is the way to go. Head over to pcisecuritystandards.org, and I think they will do a good job of getting you started.

I’ve rambled on, that’s as quick as I could. I know I sound like Speedy Gonzales here, but that’s the last three episodes in a quick touch. I want to get into this week’s episode, because I think it’s equally important that we talk about the next steps as you start to integrate third parties’ software, and your payment gateways. Now you’re on the cusp of starting to sell, and I think that this is a really neat topic. We’ve got some questions cued up here with a really cool gentleman that’s done some really neat stuff. He’s created a WordPress shopping cart solution that is really kicking ass. His whole take here is to have a really strong WordPress eCommerce plugin with secure connection services. Cart66 founder and CEO Lee Blue. My brother, how’s it going?

Lee Blue: It’s great, thank you so much for that introduction, that’s great. I really benefited from that summary that you just put forth too. You got some great information in. One of the things you mentioned was that there’s stuff that you just can’t do with a plugin alone, and that was really one of the founding ideas of why we created what we did. I’m looking forward to it, and this is going to be great.

Website security: it’s not just credit card numbers

Dre Armeda: Well, let’s kick this off. You know, pretty quickly, I think that we’ve got a lot of content to cover, so I’d like to just dive right in. When we start talking about websites and the information that is either stored or cruises through a website, it’s not just credit card numbers, or maybe it is, that need to be protected. What other kinds of eCommerce data should we be thinking about, in terms of an overall picture of security? What should we be thinking about when we start a website like that?

Lee Blue: There’s so many different pieces of content. You kind of touched on some of them in your review. There’s obviously customer information, customer names, customer addresses, order history, but there’s also stuff that is kind of prone to hacking that’s just kind of built in to your store itself, which would be like product names and descriptions and prices, and things like that. One of the hacks that we’ve seen people come to us from having had happened to them is, people will go into the actual code that is rendered in their browser, and before they actually click purchase, they’ll go in and actually change the price of a product and set their own price, kind of thing.

There’s certain shopping carts out there that don’t check against that, so that you can be on the checkout page and then, before you hit the submit button, it says you’re going to pay 20 dollars, and you’re like, “You know what, I think I’ll just change that to two.” Having checks to make sure that people are actually paying the prices that you actually think they’re paying is one, and of course, all of the personal information that gets collected on all of your customers, and what they order, and where they live, and all that stuff, that’s important.

One last piece is the shopping cart itself. For instance, a lot of people use shopping carts kind of like bookmarks. They’ll put a product in their cart and then intentionally leave the site to come back later on, so that they can purchase their product and find what they wanted to buy as a bookmark by looking at their shopping cart. You want to make sure that that stays put, as well.

Dre Armeda: So it’s not just misuse cases, it’s various use cases in eCommerce, right? Bookmarking, that’s really interesting, and I think an important note beyond the personal identifiable data and any of that information is more on the loss prevention side for the merchant, now that there’s manipulations happening to how pricing is working, and all of a sudden they’re paying a discounted rate for products that they’re buying from you.

Lee Blue: Right, exactly.

Can you keep your information locally?: secure cloud storage

Dre Armeda: That’s wild. In terms of personal identifiable data, what is your take on how that should be … We talk a lot about how that transmits over to third party processors and such. What about being stored locally? Can you give me your take on that whole piece? I know I have my direction. I don’t store anything locally if you can afford not to, right? If you can push it off to a third party that’s PCI compliant, awesome. What’s your whole take on that? As a cart provider, I’m sure you see that more than I would.

Lee Blue: Absolutely, that’s, you’re exactly right. In fact, when we first started jumping into the whole realm of eCommerce and WordPress plugins and so forth, we started out with just a plugin. That was back, like eight years ago, and everything was stored in the plugin. Then, hack, after hack, after hack would happen and every time a WordPress site gets hacked, oftentimes, it’s really no fault of your own. You can install a bunch of plugins, there can be a vulnerability in a plugin, maybe the plugin was written by somebody just getting into it and they didn’t know all the details of how to protect everything with nonces and whatever.

The next thing you know, an erroneous piece of java script sneaks onto your site, or somebody breaks in or whatever, and gets access to your WordPress database, and it happens all the time. It’s very unfortunate if you’ve got all of this, I guess I’ll use the word private information as opposed to, we tend to sensitive information or private information kind of the same way, not necessarily credit card numbers, but people’s personal information, like where they live, what they bought, things like that. It’s sitting right there in your WordPress database, and so we thought, kind of like you just said, so many people can’t really afford thousands of dollars for a secure PCI-compliant hosting providers that encrypt data and all of that stuff.

We’re like, you got to have some secure connected service so that people can affordably start storing this information. We said, “You know what, all of the information that we would consider to be eCommerce, or sensitive, or private information, we’re just going to put that in this secure cloud.” It’s going to be stuff like order history and people’s names, people’s addresses, what they bought, all of that stuff, so in the event that your WordPress site ever does get compromised, you just go fix the WordPress site, restore it so that everything looks good again, and you don’t have to serve any Viagra ads like you were just talking about, but all of your eCommerce data is sitting there, ready to go, never been exposed, and you just reconnect everything, and you’re good to go. That’s kind of the take we took, the same thing that you just said. Don’t store it locally, put it in a secure place, and now we can do it affordably.

Dre and lee’s takes on SSL certificates

Bob Dunn: All right. You guys, I’m just … Sometimes I’m just feeling like I’m going to just go and have a couple drinks at my … You know, go upstairs, of course, it’s kind of early in the day here right now, but you guys can just take this from here on in. Amazing stuff going back and forth, but, no, I’m kidding. You’re thinking you’re going to lose me here, huh? No, but loving this. What I’m thinking of, and this has been something that’s on my mind all the time is this SSL certificate. I’ve used it when I was selling, now Google is saying, “Hey, everybody should have it on their site.” Really, what is an SSL certificate, and what’s it’s role in the eCommerce security? You want to start, Dre?

Dre Armeda: I think that, yeah, actually I’d love to hear Lee’s take on this. I think it’s important to make the distinction that on the eCommerce side, certainly you’re transmitting transactional data. There is this PI, this personal data that we need to protect. We are going from the application, whether it’s Cart66 or what have you, into a third party that’s going to potentially store this information, it’s going to process all of your card data to make the transaction happen. SSLs just secure, socket layer certificates, are a means to encrypt that data as it transmits. The moment that you input this information on a form, it’s encrypted. It’s sent from point a to point b garbled in a way that no one from the outside could see what’s going on in there. They cannot determine what that data is.

That does not, I think that the huge distinction to make there is that that does not mean that you cannot transmit bad stuff from point a to point b. That’s kind of where my head’s at. We want to secure an entire site, there’s login information, there’s other forms and things like that on a site. Does not mean that if something’s not sanitized correctly, and you’re sending exploited stuff, some type of malware from point a to point b, it’s still going to transmit over that SSL certificate, it’s just no one from the outside is going to be able to see what’s happening. I think that’s the important part.

That does not mean that, if the moment you put SSL certificate on your site, that you’re completely secure from any vulnerability being exploited and malware being deployed on your site. What it means is that, from the outside, you really can’t see it anymore. It’s going to be transmitted from, again, from point a to point b, whether that’s third party service or whether you’re talking about someone inputting on a form [inaudible 00:20:42] into your database to log you in, what have you, that SSL certificate will allow that to all be encrypted, but it will not stop the vulnerability from being exploited. Does that make sense?

Lee Blue: That’s exactly right. Everything that Dre said is right on. There are obviously strong benefits to having an SSL certificate, and with Let’s Encrypt out there now, you can get them for free, and so it’s almost a no-brainer to just go ahead and get your site behind an SSL certificate.

Dre Armeda: Definitely.

The difference between SSL certificates and firewalls

Lee Blue: Google will give you some page ranking benefits to that. There’s performance benefits with HTTP/2, which is kind of like a multi-threaded approach to HTTP, which means, basically, faster loading pages. But, one of the really strong misconceptions that Dre was kind of pointing at was that the SSL certificate doesn’t actually protect your server. It just protects the communication between your browser and the server, or the server and whatever it’s talking to. For instance, it’s not a firewall. I think there’s a confusion between SSL certificates and firewalls. Firewalls actually block communication to certain ports on your server.

A port is basically a doorway. Servers segregate all communication behaviorally, in the sense that, depending on what the communication is doing, whether it’s email, or FTP, or SSH, or HTTPS, or whatever, they all have these different doorways that they go into, and each doorway has a number, and if you were going to go and say, for instance, you were going to FTP somewhere, you’d look for door number 21, and go into that door, but if you’re not using FTP, or like front page extensions, remember those? Good grief.

Dre Armeda: Good times.

Lee Blue: There’s all kinds of protocols and ways to connect to servers. SSL certificates don’t do anything at all about that. There’s one particular port that an SSL listens to and that’s it. For instance, an SSL certificate would not stop anybody from connecting by way of FTP to do something bad to your server or something like that. There’s a strong difference between firewalls and SSL certificates, and you actually want both of those things. You want an SSL certificate to make sure, like Dre was saying, that when you send data from one place to another, it actually is private and unaltered, and gets to where it’s going without any bad guys getting it, but you also want to lock the doors that are not being used, or maybe only being used by certain admin people, for instance. You want to have both of those things in the mix.

Dre Armeda: Now, you’re talking about encrypted communication, right? Again, sending something from point a to point b, you garble it up so it can’t be seen from the outside. There is a specific port, by default that’s 443, that’s HTTPS, so you see the little lock in your browser that shows green, awesome, it should be encrypted. All that communication is great, hopefully, but, again, like we said, that doesn’t talk to all the other ports, so FTP and all this other fun stuff, if you’re transmitting there, it’s just not going to cover that.

The mechanism is built in a way that, hey, now it’s going to be leveraged by the application and the third party providers to go ahead and transmit and communicate all that data, and that’s where it’s encrypted, but, again, does not mean that if something has been injected prior to that communication started, that it’s not malware that’s being transmitted from point a to point b encrypted, it just means that it’s encrypted. I think that’s a huge distinction, and I think Lee explained it magically.

It is a requirement in terms of what we consider secure communication from PCI perspective, which is, again, one of the big topics that we covered last week. We covered what PCI is, how to start with PCI, who needs to understand and implement PCI standards, and the repercussions of a data breach or stolen information by that standard, and how that’s covered.

PCI and data handling points to consider

Lee, what are some of the integration point things to consider from a PCI and data handling perspective? For example, [spend 00:25:08] at WordPress, I add Cart66, I have that SSL cert for those communications. Is that enough? What areas of WordPress and, say, Cart66 fall under PCI, and the questionnaires that we talked about last week that we should be considering? Anything that we should be talking about and thinking about as we deploy these websites?

Lee Blue: Absolutely, yeah. Like with those questionnaires, it kind of falls back to that as the foundational point from which you move forward in the sense that you want to be an SAQ A, where you can essentially say, “Somebody else does all of the payment processing for me.” The two components to … There’s basically four things that go on with processing payments that you have to think through, and two of them are usually just kind of missed in the whole process of thinking things through. For instance, the first one is storing credit card information. Everyone pretty much understands, you know what, you don’t store credit card data in my WordPress database. That’s not really an issue. The second one is processing the payment. Everyone pretty much understands, “Okay, I’m going to use Stripe,” or authorize that and that, or whatever, and the payment gateway, they’re going to process the credit cards.

The other two that people often don’t think of is the collecting and the transmitting of the credit card data. The collecting is essentially the form that you type the credit card numbers into. That’s the collecting, and then another part of that is transmitting, which is actually sending the credit card information that you do collect to the payment processor. If you’re doing either of those two things, the collecting and or the transmitting, then you’re not going to be an SAQ A, and so you’ll end up being an SAQ A-EP, which is a relatively new Self Assessment Questionnaire. I think it was edited just this year.

Dre Armeda: I think April was … Like beginning of Q2 was when it was edited.

Lee Blue: Yeah, that’s right. That basically says that if you use java script to pass credit card information from your site to another, to your gateway or what they call a direct post, where the form action tag in your payment form actually posts directly to your payment gateway, those two things actually stick you in SAQ A-EP. That kind of gets back to what we were talking about with firewalls and FTP ports, and things like that. Suddenly now, your server is in the picture because you’re basically in the process of collecting and transmitting which is, even though the credit card information doesn’t physically pass through the memory of your server, your server is still responsible for part of the payment processing, in essence, the collecting and transmitting the cardholder data, which means you now have like 130 different questions to answer.

Dre Armeda: Yeah.

Lee Blue: Even if you knew the answers, you couldn’t say, “Yes,” to them, because some of them are like, “Is the software on your server always patched within 30 days of a security release?” Well, nobody has the ability to do that with these affordable hosting packages. That’s all on the host. Probably what you were talking about with some of your hosting considerations is do they do those things?

Bob Dunn Yeah.

Lee Blue: But it’s outside of your control, so you can’t say, “Yes,” to that, or for instance, if you can FTP to your site, well FTP is an insecure protocol. It’s not encrypted, passwords are passed over clear text, and if you can FTP into your server, well then you can’t qualify for SAQ A-EP. That means you really need to get into SAQ A, which means that all of the components of your payment page need to be served from a PCI compliant server. In my opinion, there is a strong discrepancy between the two different ways that that can be pulled off.

One is through an iframe. iframes technically qualify you for SAQ A, but as we were talking about a little bit earlier just before the show started, iframes have the same vulnerabilities that transparent redirect does or java script does, in the sense that an erroneous piece of java script can sneak onto your site through a plugin, through FTP issues, or whatever it might be, and without having to alter anything about the PHP code, or the database, or API calls, or anything like that, just one little piece of java script can change the source of the iframe.

What that means is an iframe is essentially a way to pull in a form or a section of a webpage so that it looks like it’s part of your webpage, and it’s just kind of like a little window from your webpage to another, and essentially frames in a second third party site. Instead of bringing in the iframe with the payment form from your payment gateway, like Stripe, for instance, it can pull in an iframe from somewhere else. Then, of course, the big problem with that is, not only are you giving away the cardholder information to the bogus site, but you don’t know that you’re doing it, because the frame looks the same, you still have the SSL lock, there’s no alerts or warnings, or anything that anything’s gone awry, and people just start filling out their payment information with these iframes and so forth. It all is triggered with a little snippet of java script.

The best way to do it is to use a third party hosted payment page, where the entire hosted payment page is coming from a secure server. That’s the approach we’ve taken, where everybody that has a Cart66 account gets a secure hosted payment page that looks exactly like their WordPress site, because we actually skin the hosted payment page with your WordPress theme so there’s no visual disconnect when you go from your shopping experience to your checkout experience. Everything looks the same, same graphics, same navigation, everything else. The good thing is, the process of setting all that up, we have this thing called a page slurp which literally takes all of the assets from your WordPress theme, which are potentially starting out in an insecure environment, and it slurps them up and then rewrites them so that everything comes from a secured environment, so you don’t have to worry about erroneous java script or plugin vulnerabilities or anything like that redirecting any of the data that people are typing in to go to erroneous places.

How to navigate the  dangers of fake third party checkout pages

One of the other things that is an issue is, well what happens if somebody redirects to a third party hosted payment page that’s not actually your hosted payment page. That’s one of the, I think Dre mentioned it as shoplifting, or phishing, or whatever, where there’s a, you know, you’re shopping on the WordPress site, and then you go to checkout, you get redirected to a third party hosted payment page, but it’s not yours, it’s somebody else’s that’s kind of faking it.

To overcome that, the shopping cart, and the checkout page, and the view cart experience itself, all three of those things are secured in a PCI compliant server. In order to, basically, achieve one of these fake hosted payment page situations, somebody would have to actually get into your WordPress site, change API keys, the third party hosted payment page would have to implement our API, and if they don’t then you land on this fake third party page, but there’s no shopping cart content, so you immediately are aware, “Oh, wait, I don’t have any idea what I’m actually paying for, what the price is, it doesn’t look like the WordPress site,” all of these things jump into play that would trigger you. Not only do you have to get access to the server to change and rewrite PHP code, and java script won’t do the trick, because it’s an API call, not a java script sort of a thing, but there’s also visual indication that something has gone awry here because now the site looks different, or whatever was in your cart is no longer in your cart, so there’s a lot of things that will really help, both in the user experience, as well as the technical side for security.

All of that is to say, hosted payment pages are the way to go when it comes to making sure that everything stays secure, whether it be the credit card information, or the product prices, whether or not coupons are valid, all of those types of things are locked down and not stored locally, which is how we got started on this topic, so none of those things are stored locally.

Make sure your host is PCI-certified

Dre Armeda: I love it. One quick tidbit I’d like to offer is through the PCI SAQs when you’re going through all the security questionnaires, every single piece that you have in there and question in there that you need to meet in terms of the requirements are auditable. When you start thinking about, “Hey, is all of your software patched within 30 days? Yes or no,” it should be a yes to meet PCI requirements.

In the event that you’re using a host and you’re not the one managing, it’s not your own environment, and it’s kind of out of your control, one thing that is in your control is to see if that actual provider is PCI compliant, and if their certified. Let’s say for example, they’re certified to level one, they’ve got certain requirements to meet at that level. That kind of takes the onus off you, by understanding if they are certified.

For example, us, as a firewall, having a firewall is one of the requirements in PCI. We are a level one certified firewall provider at Sucuri. In the instance that you are trying to get PCI certified, and they ask do you have a firewall, “Yes, I employ Sucuri as our firewall.” Awesome. They are level one. You are now, in an audit, if they were to come down the line they would check to see what you were using in terms of a firewall, if they saw that you were using us and we’re level one, that’s it. That part of the audit is kind of moved on. That onus now has been put on us, make sure that we’re meeting the requirements as providers that are certified, versus on you that, hey, I’ve already done my due diligence, and I’ve put in the firewall that’s required for my PCI level of certification.

If you’re out there looking for a host, look for a host that’s PCI certified. If they’re level one, what have you, that’s going to be helpful in making sure that they’re meeting the requirements that you have, in terms of your questionnaires. Hope that’s helpful.

Does the type of product you sell affect how you process payments?

Bob Dunn: Yep, very good stuff. Wow. I am just, like, my brain’s just overloading right now, between you two. I thought Dre did it to me, but then we add Lee into the mix here and, you guys are just, yeah. There’s some knowledge bombs there, don’t worry Dre. I see them coming left and right. I’m dodging them too. We’re going to go into a little bit different direction, obviously, not from the topic. This is something that I’ve had a few people ask me, and I always think it is kind of an interesting question that a lot of people don’t think of. Does the type of product you sell affect how you process payments?

Dre Armeda: Ooh, Lee, I’ll let you handle that one, big guy.

Lee Blue: Okay, great. So, yes. There’s a couple of different ways that it affects what you’re selling. Right off the bat, when you try to get an account with a payment gateway, one of the things that is of strong consideration is what you’re actually selling. One of the genres of products that you can’t sell, for instance, would be like mail order brides or …

Dre Armeda: Ew.

Lee Blue:

You know, lottery tickets, and things that involve stored credit and, of course, obviously anything that involves guns or firearms or any … Although those types of things definitely affect the types of payment gateways you can use, on a more general level, the price that you end up paying for on a per-transaction basis from your gateway is also determined by the riskiness of your business and your products. In addition to what kind of products they are, like are you selling lottery tickets, or whatever, that comes into play, but also, how long have you been in business, things like that. What kind of history do you have as a business, that comes into play to see how risky your business is. Those types of things all affect the transaction cost of your payments.

You generally don’t see that in some of the popular gateways like Stripe, or even PayPal, because they have these things called aggregate payment gateways, where basically everybody signs up and is initially in the same big pot, and so the risk is spread across all the different businesses that they process transactions for, but then as you increase in scale, then one of the things that happens is you can negotiate better rates based on how much volume you do and things like that.

One-off payments vs recurring payments

That kind of affects how you process payments, but in terms of security and so forth, there’s kind of two different ball parks to play in. There’s the one-off payments, like you buy a t-shirt or a hat and you put in your credit card and you pay for it and off you go and now you have your hat, or there is the concept of anything that involves storing your credit card, and that can come in the form of recurring payments. For instance, maybe you give recurring donations to some organization that you like, or maybe you subscribe to content on a site so you get access to premium content, or anything that would involve storing your credit card, even if it’s not for necessarily a recurring payment. For instance, maybe you just want to store your billing information so the next time you go shop at the store, you can just checkout again without having to enter in your billing information all over again.

As soon as you get into the concept of storing credit card information, whether it be for recurring payments, or for repeat checkouts, or whatever, you then get into this whole separate world of how do you do that, because once a customer stores their billing information, especially if it’s for recurring payments, there’s got to be some way for them to get back in and edit that, like their credit card number needs to get updated, or whether it’s expired and the got to do something about it. You have this concept of, I guess we call it a customer portal. It’s some way that customers can get back in and manage their credit card information.

So yeah, you have to think through, “Does the payment gateway that I’m working with have a way to store these credit cards so I don’t have to store them locally? Is there a way for customers to get in there and change these numbers, to change their credit card numbers and update their customer information and so forth?” Then there’s the concept of recurring billing engines in general. Okay, so maybe there’s a way to store the information, but is there any way to schedule future payments. All of those types of things come into play when you’re thinking about security and how to do this, and the real dividing line is, “Am I doing one-off payments, where every time somebody purchases from my site, they enter their credit card and then we just kind of forget about it from that point forward, or are we actually going to do something where cardholder data is going to be stored for repeat use?” Those are the two camps that people can fall into when it comes to payment processing and how security is impacted.

Age-restricted merchandise

Bob Dunn: Wow. I was wondering, and I probably shouldn’t even bring this up, because I know we have so much to talk about already, but how about alcohol and weed? I don’t even know if you can sell weed online now.

Lee Blue: Yeah, there’s definitely, you’re kind of touching into an interesting point because there’s age-restricted merchandise in general that is a risk factor. For instance, one of the problems with selling age-restricted merchandise in general, whether it be subscription content, to age-restricted stuff online, or alcohol, or whatever, as soon as that kind of risk comes into play, there’s the concept of dramatically increased charge backs. For instance, somebody subscribes to an adult dating site, or whatever, and then somebody finds out and they’re like, “Oh, you know what, I didn’t do that,” and then they issue a charge back, when in fact, they did in fact do it, but they’re embarrassed about it, so they then say, “I didn’t do it, somebody stole my card,” and so, that is a much riskier thing and payment gateways know that, and charge you a much higher transaction rate to process that kind of stuff. Some of them, like Stripe, for instance, they say,”You know what, you can’t even do that here.” That certainly comes into play.

Payment gateway considerations for recurring payments

Bob Dunn: Okay. Very cool. With the difference between one time payments like hats and recurring payments like subscriptions, are there any payment gateway considerations when you start accepting recurring payments?

Lee Blue: Yes, so, when you have recurring payments, the thing that you have to keep in mind is credit card information is getting stored for future use. With the PCI compliance and the security and everything that we’ve talked about, if you need to change from one payment gateway to another gateway, and you’re trying to manage all of this on your own, it’s going to be a really strong challenge because you can’t receive all of the credit card … For instance, the payment gateway, can’t just export all of the credit card information and then send them to you unless you are a PCI compliant entity. For instance, they can’t just zip up everything onto a USB drive, or whatever and fling it over to your house, because that would be a violation of their terms of service and their security policies, and so forth.

Changing payment gateways is a really big problem when it comes to recurring payments. The way that we’ve handled that with Cart66 is sometimes, you want to change payment gateways, because as we talked about earlier, when you first start out, maybe you’re a fairly risky business, because you’re new to the scene, and you haven’t been in business that long and so your transaction rates are a little higher, but then, your volume goes up and so forth, and you feel like you could get a better rate with a different gateway, then that’s going to be a problem if all of your subscribers are in gateway number one, and you want to switch to gateway number two.

We’ve actually abstracted the concept of where the cardholder information is stored, so that you can switch out from any of the over 100 different gateways that are supported by Cart66, so you can start with Stripe, and flip over to Authorize.net at any time, or whatever you want, without having to ask your customers to resubscribe. That’s generally what ends up happening, if you’re just a regular guy like everybody seems to be, you can’t just accept this big bucket of payment card data shipped to your front door, so you end up saying, “Well, okay, I can get such a better rate. I really want to switch to gateway number two, and then I’m just going to ask all of my subscribers to reenter their billing information,” and of course, when you do that, you lose subscribers, it’s a pain in the neck, everybody’s frustrated, and so that is definitely a consideration.

If you’re not using Cart66, that’s of course, fine, but you want to make sure that you’re thinking through, “Okay, maybe the transaction rates that I’m getting are a little bit higher,” or, “Maybe it’s a little bit more trouble to set this gateway up,” or whatever, but you do kind of have a little bit of a marriage with your payment gateway when it comes to storing credit card information because it’s such a pain to switch, unless you have some sort of an abstraction layer, like we’ve provided.

Do eCommerce features affect site security needs?

Bob Dunn: Okay, excellent. That does clarify that part of it. Okay, Lee, another question. What eCommerce features have an impact on the security you need for your website?

Lee Blue: That’s a great question, because we talked a little bit about recurring payments and one-time payments, and the difference between needing to actually store cardholder information for future use, versus not needing to do that, so that’s obviously one big thing. There’s even more subtle differences. For instance, if you’re selling digital products, you probably don’t collect shipping addresses from people, so there’s less personal identifying information when you sell digital products compared to physical products, in the sense that if you’re going to ship something to somebody, you need to know the shipping address.

Another thing though, too, is when you’re selling digital products, while maybe you don’t have to worry about shipping addresses, you suddenly have other security concerns, like for instance, you don’t want people to, like if you’re storing the digital file that you’re actually selling on your WordPress site somewhere, like somewhere in the WP content uploads folder or something like that, you need to make sure that, if somebody happens to figure out the path to that file, they can’t just share it, or directly link to it and download it as many times as they want, and so forth. That’s a big deal, or how many times paying customers can download files. That’s another, like maybe if somebody buys an album, an MP3 album or something from you and you say, “Okay, yeah, you can download it up to five times,” you might want to have restrictions in place like that, so you want to make sure that whatever eCommerce system you’re using can handle that kind of customization.

Then there’s, I guess, maybe more of a performance issue. For instance, if you’re serving these digital files, especially if it’s a video file, and it requires significant amount of time to download, you don’t want to clog up your actual WordPress site by having these gigantic files being streamed down all the time, and so, kind of like what Dre was saying earlier in the talk here with regard to cloud based performance enhancements from content delivery networks, if you have a content delivery network to securely store and deliver your digital products, that’s going to be a much better way to go about delivering digital files. Of course, then, you need to make sure that you have all of that set up securely, as well.

Dre Armeda: A point to add there is you talked a little bit about digital downloads, knowing the path and all that, which is super important, certainly, from a loss prevention standpoint, you want to make sure that that’s safeguarded, protected, how many downloads, all of that fun stuff. The other piece is making sure that the integrity of those files, of those digital downloads are not compromised.

Lee Blue: Good point.

Dre Armeda: We’ve seen attacks in the past where they didn’t really give two hoots about the vendor’s website, but they found these digital downloads and implemented malware within those downloads, with update requests. All of a sudden, the entire user base of that actual digital download or that software platform, is now injected with this malware through their update. All of a sudden, it’s attack all instead of just the vendor. That is an important piece of making sure that you’re safeguarding that actual IP before it’s exploited. That’s one piece of it.

The other side of that is, look, let’s take it back to [brass tacks 00:48:26] here, Bob. We talked about he holy grail, and it’s the data. It’s going to vary based on what you’re selling, it could be a hard product, you’ve got address info and things like that stored, which is sensitive, but ultimately people are purchasing stuff, and it really comes back down to that payment information. All of that data is important, and it needs to be safeguarded, no matter what you’re selling, what features on the site. Shipping information, things of that nature, so that there’s third party integrations for shipping and things like that, how are those being protected? Again, it comes back down to protecting all of that data.

Tools for enhancing eCommerce security

Bob Dunn: Lets end this with a little bit of a wrap up, but also in terms of overall eCommerce security, give us some recommendations of so called tools that, maybe, should be used in your overall eCommerce security.

Dre Armeda: Fire away, Lee.

Lee Blue: Well, getting yourself set up with a security account seems like the first step of the process, because I mean, that just takes such a big swath out of all of the issues. You’ve got yourself a content delivery network, you’ve got a web application firewall, you’ve got a team of people that can help you if your site does get hacked, they can fix it. There’s knowledge about how to prevent that in the first place. One of the personally satisfying things about being a security customer is looking at that screen that says, “Here’s all the stuff that could have caused problems but it never even reached your website.” Before, my website had to do, or your application, or whatever. Whatever it is that you’re actually hosting, before that has to even do anything, the guys over at security are just blocking all kinds of stuff. I think that’s a great way to get started.

Of course, on top of that, if your host has the ability to hook you up with an SSL certificate, especially if it’s for free, like through Let’s Encrypt, which is free to install now, that’s another really good step in the right direction. There are, of course, plugins that you can use in WordPress to monitor things like Dre was just talking about, about file integrity and lockins to make sure people aren’t trying to log into your site over and over and over, or accessing files that don’t exist over and over and over, you can start blocking those types of people. Of course, security will take care of that for you, as well.

Then, as far as PCI compliance is concerned, trying to find some sort of a shopping cart solution that you feel comfortable with, that enables you to store as much of the sensitive information off of your WordPress site as possible, especially when it comes to cardholder data, but, perhaps, not just that, but also customer information and other eCommerce data, as well. Those are all great tools to look into.

Dre Armeda: You know what, I’m going to expand on that, Lee, a little bit, because it’s not just about the shopping cart experience that you’re comfortable with, but one that is secure and really a responsible party in ensuring that your payment information and your private information is properly secured and is using best practices to minimize your risk floor. Cart66 is that partner, you guys need to consider what you’re doing there for you, and your clients, and your long term growth. They give you the opportunity to [scale 00:51:47] when you need to. They really have it in mind, and in fact, if you go over their blog, they’ve got a lot of great articles and discussion points around their common approaches to security and why they’re the most secure eCommerce solution out there for WordPress.

I’ve talked a lot about layered security, defense in depth, and that’s really what it comes down to. Lee just mentioned SSL certificates from your hosting provider, Let’s Encrypt offers them for free and it’s pretty neat. We’ve actually partnered up with the, so if you’re using the Sucuri firewall, you have access to Let’s Encrypt SSL certificates. That’s something that you should be considering across any transactional site, any site at this point. We talked about some of the performance gains, and even SEO value you get from using SSL certificates, so even if you’re not using a commerce site, today, you should consider for any website that you have out there.

PCI compliance, use it as a staple for anything that you’re going to be doing in moving forward if it’s transaction or if you’re processing payment cards. That is a great standard to follow. Their questionnaires will really put you in a place to mitigate or reduce risk as much as possible for you and your clients, and making sure that any of that sensitive information is not ending up in the wrong hands. That would be my first take.

Again, defense in depth. Add a web application firewall. It is a PCI requirement, but also something that’s going to minimize the opportunity for attackers coming in and doing funny stuff on your site. For example, the security firewall offers, not just DDoS mitigation at the edge, we kind of sit between your website and the internet, but we also have virtual patching. For example, obviously you should be updating your stuff and keeping it up to date. Sometimes it’s not practical to apply brand new patches right away. Again, PCI dictates 30 days, so make sure you’re doing it as quick as possible; however, sometimes it’s not feasible to do it right away.

We have application patching at the edge. We know what we know about websites and different software out there. WordPress, Drupal, or what have you. We know what calls are supposed to be happening from these software solutions. When an actual request comes in a known vulnerability or to inject something into a known vulnerability, we have these things cataloged, so we’re able to stop these things at the edge. That gives you the opportunity to add, again, that extra layer in the event that you maybe run in some type of known vulnerability on your website.

Web application firewall, again, plugins inside of your environment checking things like, “Hey, who’s trying to log into my site? Why have I had 20 different attempted log ins for admin and I’m the only one with an admin credential?” You know that these things are getting stopped in terms of brute force, things like that. Any time you can do integrity checks on the server, or in your environment with a plugin, that’s great. Make sure that nothing’s changing there. Again, think about what you value most. Think about the value of your client and customer information, about your content and everything else, and think about the controls that you can implement to minimize your risk of that stuff being exploited.

That would be my take. It’s been a pleasure being on the show, the last four episodes, Bob, and we’re excited to talk about security as much as possible because the repetition really helps change the way that we all think about it. You need to take a holistic approach to security. It’s not just about not using password for your password, which is important, but thinking about the entire environment from the moment you log in to the networks that you’re connecting to do work, to your hosting providers, and that entire environment. The software that sits under your application where you’re logging in. How you’re connecting. There’s a lot of things to consider when it comes to security, all very important in terms of minimizing risk of attack and exploitation, so do your best to implement these controls.

You can always come ask us questions at sucuri.net, s-u-c-u-r-i.net, and if you’re looking for information around current vulnerabilities and even some how-to’s, if you head over to blog.sucuri.net, we can help you out. We pump a lot of content out weekly to help folks, educate folks and help people out. Or find us on Facebook or Twitter, sucuri security.

Again, I appreciate you having me on. Lee, thanks for joining us, man. It’s been a knowledge bomb in the making.

Thanks, Lee, from Cart66

Lee Blue: Well thank you guys. I really enjoyed it. This was a really great experience and you guys have really cool voices, and so I’m jealous of your voices, and excellent podcast voices, and I’ll have to practice that to see if I can get up to speed. I certainly do appreciate the opportunity to talk to you guys. It’s been fun. Thank you, Bob, for putting all this together and arranging it, and maybe we can do it again some time. I really had a great time.

Bob Dunn: Okay, cool.

Thanks, Dre, from Sucuri—and sign up for his upcoming security podcast!

Dre Armeda: Awesome, you guys. If I may, Bob, we have, for all your agency freelancers and project organizations out there, I’m doing a podcast November 3rd if you head over to our site, you can sign up for that, and it’s how you can start thinking about implementing security for your client projects, again, as an agency freelancer. It’s important that, one, we influence people to do the right thing in terms of managing their site, but also provide you the opportunity for new revenue opportunities. Come check us out.

Bob Dunn: Well, thank you, Lee. I really appreciate that. I hope everybody does check out Cart66.com. Dre, if I could possibly hug you right now, and your whole team at Sucuri, I would do it. I don’t know if I have big enough arms, but I would certainly stretch and make it possible.

Dre Armeda: It was great chatting with you.

Bob Dunn: So, what we’re going to be doing with this particular series is I’ll be posting the entire series in one single post on BobWP here, as well as offering a single download that will include all four shows and single PDF with all four show notes, for your convenience. Of course, the single podcast episodes and show notes will still be available on our blog. I want to thank everybody that’s tuned in, and be sure to share this series with anyone you know that runs an online store to help them get a better understanding about how they can make sure their customers’ information and all that other stuff is safe and secure. Keep an eye out for the next time we are able to bring you yet another series, and of course, tune in each Wednesday as we bring you another episode of the WP eCommerce Show.