We recently consulted on an incident where a bad actor compromised a large ecommerce website. They were able to manipulate elements of the checkout page to hijack the users card information.
They targeted an onclick action when the user clicked “continue”. While the platform was not storing the data locally, they had local scripts capturing the information momentarily in memory before pushing it to the gateways secure API. This configuration introduced a vulnerability in their system, exposing them to an online skimming attack.
The attack itself side-loaded a third-party Javascript into the application when rendered in the browser. This vulnerability was exposed because of two misconfigurations:
- Self-Hosting a Payment Page;
- Allowing sideloading of third-party scripts;
This was an expensive lesson to learn and in this article we explore these two items to ensure we help you reduce the risk in your own ecommerce environment.
Self-Hosted vs Hosted Payment Pages / Forms
The difference between self-hosted and hosted payment pages lies in how card information is collected and processed.
Self-Hosted Payment Page
In self-hosted payment pages, the website owner handles all, or some part of the collection and processing of card information. Even if you’re only capturing and storing in memory to push to a secure API via a POST request, this is considered a form of a self-hosted solution.
Hosted Payment Page
In a hosted payment page, the website owner hands off the responsibility of collection and processing of card information to the payment gateway (e.g., PayPal, Stripe, Recurly, etc..).
In today’s modern online world, the defacto standard when creating a payment page is to have your payment gateway / processor take ownership of all things related to the users card data. This means always use a Hosted Payment page or form in your own application. If you’re using a closed platform like Shopify, etc, this won’t apply to you as this is already done on your behalf. This is specific to website owners that self-hosting with their own platform (e.g., WordPress, Magento, etc..).
While this would have dramatically reduced the risk in the scenario above, it was only one piece of the puzzle.
Minimizing Risk with Security Headers
The second piece of the intro scenario was the bad actors ability to side-load a Javascript payload from a third-party domain. This was achieved because the application was not configured to prevent side-loading scripts from unknown sources. To address this, we turn our attention to security headers.
Security headers are HTTP response headers that provide instructions to web browsers on how to handle various aspects of a web page’s security. By leveraging these headers, an ecommerce website can enhance its defenses against common web vulnerabilities and ensure a safer online shopping experience for users.
There are a number of different security headers worth noting, and the link above talks to each. For this specific scenario, however, we want to talk about one that would have had a material impact in this attack:
Content Security Policy (CSP
Content Security Policy (CSP) headers are critical in web security, they help mitigate the risk of various types of attacks, such as Cross-Site Scripting (XSS) and other forms of data injection. When it comes to hosted payment pages or forms, CSP headers are relevant and can be configured to enhance the security of the entire web application.
CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. Put in the context of the attack in this article, sideloading a Javascript payload from another domain would not have been possible with CSP enabled.
The Modern Web Mandates Hosted Payment Pages and Forms
The security of payment transactions online is non-negotiable. It’s also a compliance issue.
If you’re an ecommerce platform you have an obligation to comply with standards set forth by the Payment Card Industry Data Security Standard (PCI DSS). While you definitely can self-host, it opens you up to a world of pain with compliance. Alternatively, using a hosted solution transfers the risk and liability to a third-party while still offering your customers the seamless experience they may be accustomed to.
Lastly, security headers are a powerful tool in offering a defense against a variety of online threats against your website. Investing in the implementation of security headers can have a material, positive, impact on protecting customer data, especially headers like content security policy (CSP) that help avoid loading of third-party scripts.