Our Mission: Simple, Easy, and Stigma-Free Campus Transactions
December 20, 2020
The Website Content PAN Attack
The vast majority of e-commerce sites collect credit card data directly in the cart. There are several sound reasons for this including: ease of use for the customer, ensuring a totally consistent experience, POS integration for charges and refunds, etc. Unfortunately, this also makes it easy for an attacker. If the attacker compromises the site in a way that allows them to change the content for the customer, then they can easily add their own malicious code – known as a “payload” – which can record card data and send it to the attacker.
Here is an overview of the attack at a high-level:
How does the attack work?
Step 1: The attacker defeats security in the web server or content storage for the site and modifies the site to deliver their malicious payload as part of the “cart”. This is transparent to the user and to browser security tools since the payload is coming from your site.
Step 2: The customer enters their PAN data into the form in the cart. The browser shows “secure”, and there is no sign that the cart is compromised. Neither the customer or the retailer’s site can tell there is something wrong.
Step 3: The attacker’s payload records payment data directly from the form as it is entered and sends it to the attacker. Since this doesn’t necessarily require the payload to communicate with your server again, it isn’t obvious that theft has occurred.
This type of attack is, unfortunately, much too common in some industries. In higher education, as an example, there was a major e-commerce provider that fell victim to this type of attack multiple times in a single year. What’s more, this type of attack is entirely preventable. The short version is that your e-commerce site shouldn’t handle the credit card data. Furthermore, the merchant’s servers should never hold PAN data (credit card information) for any reason.
As an example of how that can work, here is how Watchman Payment Systems e-commerce tokenizer secures the same process – even when an attacker has successfully attacked and deployed a payload to your e-commerce site:
How can I protect against it?
Step 1: The attacker defeats security in the web server or content storage for the site and modifies the site to deliver their malicious payload as part of the “cart”.
Step 2: The customer enters their PAN data into the form in the cart. Transparently to the customer, the PAN data is handled by our tokenizer. The form looks like every other form on the site, and there are no extra steps or different branding, but since the data is entered into the WPS fields, the card data never reaches the compromised server.
Step 3: The attacker’s payload cannot see the contents of the WPS fields, so it can’t record the PAN data – meaning it can’t send it to the attacker. Any other data on the form that is sent to the attacker is useless.
For sites using in-site tokenization from WPS, even a compromised website can’t deliver card data to an attacker. Our solution provides the same validated level of tokenization to the web that we use in our on-premise solutions. The e-commerce site literally never has the card number, so it doesn’t have the ability to leak it to an attacker. This is done without requiring any additional steps in the check-out process, and without losing consistency on the web form. Your customer only sees your site. The site never sees the card. We handle the rest. (Oh, and, if needed, we can ensure that the result is reusable – for rentals, subscriptions, refunds, and other approved uses.)
