You are here

You are here

Try harder: CSP won’t save you from Magecart-style attacks

Richi Jennings Your humble blogwatcher, dba RJA

A new hacker trick to exfiltrate data is revealing old security weaknesses. Seems some sites rely a little too heavily on Content Security Policy (CSP).

Web skimmers, using Magecart and similar malware, have found a way to send their stolen data via Google Analytics. This sidesteps any CSP rules requiring client-side data be sent only to trusted domains.

It proves, yet again, that DevSecOps needs a “defense in depth” strategy, rather than relying on just one or two silver bullets. In this week’s Security Blogwatch, we lock and load for bear.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Startups.

New trick in the wild

What’s the craic? Sergiu Gatlan reports—Hackers use Google Analytics to steal credit cards, bypass CSP:

A new method to bypass Content Security Policy (CSP) using the Google Analytics API … has already been deployed in ongoing Magecart attacks designed to scrape credit card data from several dozen e-commerce sites. [It] takes advantage of the fact that e-commerce web sites … are whitelisting Google Analytics domains in their CSP configuration.

Attackers [use] a web skimmer script that is specifically designed to encode stolen … harvested info such as credentials, credit card data, and more … and deliver it to the attacker's GA dashboard. … Since March [there have been] attackers abusing this exact issue to bypass CSP on several dozen e-commerce sites using Google Analytics.

Based on these findings, CSP is far from a foolproof against injection-based web app attacks such as Magecart.

And Dan Goodin adds—Crooks abuse Google Analytics to conceal theft of payment card data:

Payment card skimming used to refer solely to the practice of infecting point-of-sale machines in brick-and-mortar stores. … More recently, these sorts of attacks have expanded to use against ecommerce sites [with] unauthorized code that runs deep inside the back-end system that receives and processes payment card data during an online transaction.

Payment card skimming on websites has remained a problem, particularly for people shopping with smaller online merchants who don’t pay enough attention to securing their systems. … Larger sites are less prone to these sorts of hacks.

In a statement … a Google spokesman wrote: “We were recently notified of this activity and immediately suspended the offending accounts for violating our terms of service. When we find unauthorized use of Google Analytics, we take action.”

Who brought this to our attention? Amir Shaked—Exfiltrating User’s Private Data Using Google Analytics to Bypass CSP:

Content Security Policy (CSP) is a useful tool for protecting web applications against client-side vulnerabilities. … However, CSP has its limitations. It is difficult to manage and does not offer protection against compromised hosts that are already whitelisted.

Designed to guard against XSS attacks, CSP helps control which domains can be accessed as part of a page. … Using the Google Analytics API, a web skimmer can send data to be collected in his own account instance.

The source of the problem is that the CSP rule system isn’t granular enough. … A possible solution would come from adaptive URLs, adding the ID as part of the URL or subdomain to allow admins to set CSP rules that restrict data exfiltration to other accounts.

A more granular future direction for strengthening CSP direction to consider as part of the CSP standard is XHR proxy enforcement. This will essentially create a client-side WAF that can enforce a policy on where specific data field are allowed to be transmitted. … While CSP is a useful tool … it is not foolproof.

And what about in the wild? Sansec’s anonymous researchers blog thuswise—Digital skimmer runs entirely on Google:

When a skimming campaign runs entirely on trusted Google servers, very few security systems will flag it as “suspicious.” And … popular counter measures like … CSP will not work when a site administrator trusts Google. … CSP is practically worthless when you already have Google Analytics.

Since March 17th, several dozen stores have been injected with the loader, which runs on Google’s open storage platform … It creates a temporary iFrame that loads a Google Analytics account under control of the attacker. … When a victim enters his/her credit card data, it gets encrypted and then sent as custom Analytics event to Google.

Verily, Victoria Vlasova validates veracity: [You’re fired—Ed.]

The principle is quite simple: malicious code is injected into the compromised site, which collects and sends user-entered data to a cybercriminal resource. … To harvest data about visitors using Google Analytics, the site owner must configure the tracking parameters in their account on, get the tracking ID … and insert it into the web pages together with the tracking code.

Recently, we identified several cases where this service was misused. … We found about two dozen infected sites worldwide [including] stores in Europe and North and South America selling digital equipment, cosmetics, food products, spare parts etc.

The script collects everything anyone inputs on the site (as well as information about the user who entered the data: IP address, UserAgent, time zone).

How to avoid the issues: …
Do not install web applications and CMS components from untrusted sources. Keep all software up to date. Follow news about vulnerabilities and take recommended actions to patch them.
Create strong passwords for all administration accounts.
Limit user rights to the minimum necessary. Keep track of the number of users who have access to service interfaces.
Filter user-entered data and query parameters to prevent third-party code injection.
For e-commerce sites … use PCI DSS-compliant payment gateways.

In case it’s unclear, Errol backfiring reminds us how this starts:

This is just half of the story. The attackers must be able to inject their code into the website, even if there is a Content Security Policy active.

If the CSP is not active, they might as well send the data to their own server. I am curious how they inject their code in the first place.

JavaScript considered harmful? M@yeulC is easy for you to say:

This is one of the reasons I block all third-party JavaScript by default.

Unfortunately, e-commerce sites are extremely JavaScript heavy, and often have 30 or more random dependencies (Cloudflare, Google Analytics, cdnjs, jquery and whatnot), some of which are required for the website to work properly, even on the payment page. And more often than not, the payment processor is a third party as well, which makes it hard to selectively allow.

And Rosco P. Coltrane waxes sympathetic:

Google Analytics is … popular with website operators. [But] those technically inclined enough to be aware of what it is block it, and those who aren't, aren't even aware they're being tracked.

But it’s a constant pain. So says jdale:

I constantly have to go through and selectively enable scripts to allow pages to load. It is a pain. But I do it because I figure the consequences of just leaving things open will eventually be even more of a pain.

I do not comprehend what kind of messed up mindset leads a company to think they should install dozens of tracking scripts they have not vetted on their own checkout pages. There is all kinds of malicious behavior that enables. Yet it's extremely common.

Is it possible that rtb61 goes a touch too far?

Google, yeah, as evil as it gets: It's corrupt invasion of privacy and targeted manipulation of citizens, not just for commercial reasons but for political reasons and that is a ****ing evil as it gets in a democracy.

Meanwhile, Sajuuk cuts to the chase:

Google or no Google, if I can control your infrastructure, I can get your user's data.

The moral of the story?

Practice defense in depth: CSP alone is not enough. Do you know what all the scripts on your pages do?

And finally

Someone has too much time on their hands

Hat tip: Rob Beschizza

Previously in “And finally”

You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or Ask your doctor before reading. Your mileage may vary. E&OE. 30.

This week’s heroic pic via rupixen.

Keep learning

Read more articles about: SecurityInformation Security