How cardholder data can be stolen before it reaches the Merchant

In a couple of recent attacks cardholder data has been stolen even before it entered the merchant's or payment processors systems. In fact it is stolen from within the browser the cardholder was using to enter their payment card details. This attack, even although the card data theft is not actually occurring in a merchant's system is the result of a security weakness with the merchant's security.

The attack is a Cross Site Scripting Inclusion (XSSI) attack and on a simply level it occurs where a payment page has a link to a script hosted on another domain that provides functionality the merchant required. Due to the nature of how the script is called, it bypasses the principle of the same-origin policy and allows the script which is from a different domain to the hosted page, to read the document object model (DOM) of the page it is called from, giving it the ability to read the contents of forms such as those contain card holder data. If that script is malicious or compromised through a security failing on the part of the provider who is hosting it then the merchant's page is compromised. The merchant's security failure is failing to recognizing the risk of using an external hosted script and ensuring it is secured. There are techniques such as Sub-Resource Integrity (SRI) that can be used to determine if a called script has been compromised through the use of cryptographic hashes. Additionally the supplier of the script is part of the supply chain and the security of the script and hosting paltform should be part of the due diligence checks on the supplier.

A typical attacker scenario would be an attacker looking to compromise card data will find a merchant with payment page, examine the source code and DOM of the page using a web proxy and other tools and identify the use of an externally hosted script. The attacker will then examine the security of script hosting platform and if possible compromise any vulnerabilities and replaced the existing script with a malicious script designed to scrape the payment forms and send the harvested data to systems the attacker has access to, often other compromised systems.

The flow of the attack is described below

1)     Attackers compromised the 3^rd party’s server through a vulnerability and replace scripts on that server that are used by merchants with malicious code.

2)     A cardholder clicking on checkout caused their browser to request the payment page to be called from the merchant’s server.

3)     The page contained a link to the 3^rd party’s hosted JavaScript is rendered in the browser the link is executed and the browser requests the JavaScript

4)     The previously compromised script is loaded from the 3^rd party’s server and executed in the browser

5)     As cardholder details are entered in to the fields within the payment form the malicious script reads them and sends them to the attacker’s server

The scenario and diagram show how XSSI can be used to compromise data in a browser rather than a merchants own systems and often through a system that does not belong to the merchant. It shows how attackers are looking at end points where security may be lower than an internal system owned by a merchant. Merchants recognize having an internal systems processing card data is at high likelihood of being attacked and outsource payment processing using techniques such as silent order posting to send data direct from a form within a browser to the payment processor but a simple script can provide the foothold an attacker needs to steal payment cards before reaching the merchant or payment processor.