Compromises of e-commerce websites are increasingly common. In our 2012 Global Security Report we reported that 20% of our incident response investigations related to e-commerce sites. This was up from 9% the year before. In my part of the world (Asia-Pacific), this figure is closer to 40%. In almost all of these cases the motive was simple - the theft of credit card data.
In order to better defend against e-commerce attacks, we must first understand them better. In our experience, there are three common methods for e-commerce sites to accept payment cards.
Store and download
This is the most common method for smaller merchants, especially those that have augmented their pre-existing physical store with an e-commerce outlet. These merchants already have a method of accepting payment card transactions in their store. Instead of getting a second merchant facility for their website, they download the payment card data relating to new orders from their server and manually enter this into their existing facility. As a result of this, payment card data has to be stored somewhere, usually on their web server.
Third-party gateway via API
Larger merchants tend to favour this option, as it gives them a seamless customer experience and enables them to authorise payment cards at the time of purchase. The customer submits their payment card data to the merchant's website during the checkout process. The merchant's website then passes this directly onto a third-party for authorisation. Using this method there is no reason for payment card data to be stored on the merchant's server nor is there any need for a customer to be redirected away from the merchant's website.
Hosted or direct third-party gateway
The goal of hosted and direct payment models is to ensure that the merchant's web server never sees payment card data. In a hosted model, the customer is redirected to a third-party during the check out process. This third party then presents the customer with a form to enter their card data into, processes this transaction and redirects the customer back to the merchant site.
A direct payment model is very similar, except that the credit card form is actually hosted on the merchant's website, but when the customer submits this form the data is sent directly to the third-party instead of back to the merchant.
All of these methods are susceptible to attack in certain circumstances. In general we see three different styles of attack:
- Stored data - As the names suggests, an attacker simply locates and copies stored payment card data. This is very common for "store and download" merchants, but also happens to API merchants that are storing payment card data inadvertently.
- In-transit - In a well-implemented merchant environment using an API payment model, there will not be any stored payment card data. As a result, an attacker needs to intercept data at the time that a transaction is made. Attackers commonly do this by saving a copy of every request sent to the payment gateway to a file that they can then download, or having a copy of each transaction e-mailed to them.
- Bait and switch - Whilst hosted and direct payment models dramatically reduce the risk of compromise for most smaller merchants, they do not completely eradicate the possibility of a compromise. By changing the destination that a customer is redirected to or the location that payment card data is sent to, the attacker can inject themselves into the transaction flow and capture payment card data.
For example, an attacker could modify a merchant's website to direct their customers to evil-payment-company.com instead of good-payment-company.com. The attackers can make the website of evil-payment-company.com look identical to good-payment-company.com and even send a copy of the data captured by evil-payment-company.com to good-payment-company.com so the merchant still receives payment for their order. We've worked on cases where this has occurred and where it has gone unnoticed for several months.
This blog post has given you an introduction into how most merchants accept payments and how most bad guys steal this data. In part 2 I'll delve into the misconceptions about e-commerce security that we hear every day.
