Last updated at Wed, 15 May 2019 14:13:25 GMT

This blog was originally published at blog.tcell.io.

The current trendy attack against retailers is the use of scripts to skim credit card information, best known as a series of attacks by the Magecart group (believed to behind the British Airways and Newegg breaches). This begs the question of why retail is so bad at application security and what can be done to defend against this type of breach.

How can you defend against these attacks? HTTP's Content Security Policy is a flexible tool that enables application administrators to control which browsers are allowed to connect while using the application.

In brief, a Magecart-style attack works by inserting a script into the victim's site, whether by compromising a third-party component or by compromising the code for the victim's site itself. Once loaded and executed, a script can take any information off the page, including a component frame, and send data to a server controlled by the attacker. The flow looks something like this:

  1. Breach either a victim website or a third party they depend on. The attacker doesn't actually exploit the vulnerability yet, but they know there is a victim in-waiting.
  2. Set up the infrastructure to collect compromised data (ex: register a domain and set up a server). This is shown in the picture below as badguys.com, a newly registered domain in which attackers can set up a server to receive skimmed data. In practice, attackers will try to set up a domain that looks "normal." For example, even though they had no affiliation with Newegg, they registered the innocent-looking neweggstats.com.
  3. Insert a malicious script into the relevant page, either by exploiting a vulnerability in the web server or a third-party component. Now, the attack begins, and the script takes data from the payment page and sends the skimmed data to badguys.com.

CSP interrupts the attack when the skimmed data is communicated. In theory, it would be possible to work to defeat the attacker at either of the previous steps, but it's safe to assume that most security departments already expend maximum effort defending their website (step one), and that security departments have no special knowledge of what domain registrars do (step two).

To prevent the skimmer script from reporting data, you can set a Content Security Policy on the web application to control where it is allowed to connect. A CSP can be set to allow connections to only known sites that you control. For example, if you saw your web page trying to send data to CollectStolenPaymentInfo.com, you probably would be suspicious and disallow that.

It is not enough to set up a CSP policy. Applications are dynamic, and developers can add new website components. As part of its browser security components, tCell includes a managed CSP solution that automatically inserts a Content Security Policy header, then collects reports from browsers to assist with configuring the right policy.

Browsers send CSP reports indicating when the web application tries to connect to servers outside the configured policy. Here is a screenshot from our demo system that shows a demo web application that is trying to connect to ads.google.com, ajax.googleapis.com, and com5p2.net.

So, as a security administrator, you start from knowing what the application is trying to do. In most cases, you know whether you're using Google Ads or APIs, and would add those domains into the CSP configuration. When new domains pop up, they'll be listed with a reputation score. The reputation score can tell you quite a lot about whether a domain is part of an attack because it aggregates various signals of trust into one score. (See this list of reputation services.)

For example, let's consider the collection domain used in the Newegg attack, Neweggstats.com. It's clearly meant to evoke something trustworthy for the site administrators and to be added to filtering rules somewhere without much thought. It's easy to imagine somebody at a security console saying, "I guess we might have registered (our-domain)+stats.com..." Reputation services guard against this by quantifying risk.

Rather than just seeing the newly registered domain name, a reputation score will take into account other factors, such as:

  • Newly registered domains are more suspicious because it's unclear how they are being used.
  • Less-used domains are more suspicious.
  • Domain-validated certificates are more suspicious than extended-validation certificates because there is less-robust checking.

If we look at the neweggstats.com domain in the BrightCloud reputation service, it's shown as high-risk because it's a newly registered domain with low popularity that has hosted one attack.

So, there you have it. To protect against skimming attacks, enable CSP, look through CSP reports to see whether the application is connecting to, and use reputation services to understand whether those sites are risky.