Today’s whitelisted applications are tomorrow’s security breaches

by Michael Rogers on July 8, 2020

You may have seen the news last week, but if you haven’t, let me bring you up to speed. The research team at PerimeterX disclosed a “CSP bypass” involving the use of Google Analytics. Naturally, this generated a lot of buzz – which is great if the nature of the problem is accurately described. In reality, this is not so much a CSP bypass as it is a loophole being exploited in Google Analytics (more on that later).

As the saying goes, truth and clarity are complementary, so let’s start by looking at how the bypass works.

CSP uses a positive security model. Simply put, all actions must be whitelisted and those that aren’t are completely blocked. For example, if https://www.google-analytics.com is not explicitly whitelisted, any attempt to load a script or send data (script-src, connect-src) from https://www.google-analytics.com would fail. So far, so good.

Sponsorships Available

The problem, as correctly pointed out in the blog post, is that because Google Analytics is whitelisted for receiving data, an attacker who inserts code in your page – in any of the myriad ways this can be accomplished– can also insert their Google Analytics ID as a Google Analytics destination for malicious purposes. No amount of CSP will stop that.

While this is true, this isn’t a CSP bypass, it’s a Google authentication issue. And there is no doubt that Google is thinking about how best to handle this situation.

Highlighting Google is a good strategy for attracting attention, and to be fair the authors have revealed a fundamental security flaw: data leakage caused by legitimate third-party integrations. But the problem is way bigger than Google.

Bigger than Google

What wasn’t really underlined by the researchers is that this isn’t a problem unique to Google Analytics. It’s something you need to consider for ALL whitelisted resources.

When you whitelist something, you need to be able to understand exactly what the script resource can access, as well as monitor and control any data exfiltration. Without proactive monitoring and granular control, today’s whitelisted integrations are tomorrow’s security headlines. While it’s true that legitimate third-party integrations provide access to sensitive data, doing so without the site owner’s knowledge or ability to enforce permissions creates exposure risk and has led to significant data breaches.

How to Solve It

At Tala, we’re constantly working on ways to solve the security issues generated by the modern web. Understanding that legitimate third-party JavaScript services could be used in data-exfiltration isn’t really news. Instead of blogging about the problem, we solved it with a data leakage feature designed specifically to prevent it: PII Exposure Scanning and PII Leakage Mapping.

Working with Tala’s patented analytics engine, these features enable the fine-tuning of policies that prevent sensitive data exfiltration from trusted applications. We synthetically monitor data mapping to identify sensitive data leakage, without customers having to install or instrument anything on their web apps. Our analytics engine dynamically scans for this specific data leakage. Users can create customized data patterns and types to define data destination policies, similar to DLP for web applications. An alert is generated when any sensitive data violates policy-defined permissions or is identified as suspicious by analytics.

This kind of insight into application behavior is critical, because simply knowing that third-party services are capable of collecting data isn’t the same as knowing when they are doing this. Monitoring, together with dynamic prevention, significantly reduces the risk of whitelisted applications accessing or stealing data.

It’s all about the data

CSP is a wonderful and important security control, but like every other security control, it shouldn’t come as a revelation that it doesn’t solve every problem – even theoretical, manufactured exploits. Designed by the industry’s leading experts, CSP is deployed at the world’s most security-forward companies, like Google. There is a clear case for implementing effective CSP as part of a broader strength-in-depth approach to securing web applications, which is why organizations that take web security seriously are investigating or deploying comprehensive standards-based security, including SRI, HSTS, Referrer-Policy, Feature-Policy, Trusted Types and more.

It’s not just about standards either: at Tala, we’re taking the growing third-party data leakage problem very seriously. GDPR, CCPA and other privacy regulations place responsibility on website owners to control the way their web applications access and share data. And while third-party integrations like Google Analytics are obvious potential sources of risk, it’s important to know that this extends to any code on your site that enables access to data collected by your web applications.

We’re really excited about our new data leakage protection capability and would love to show you how it solves this and other web application security and data integrity problems. Book your DEMO with Tala today and see how you can scan for these risks, monitor exactly what’s going on with your whitelisted applications and automate the deployment of the most comprehensive set of security standards and controls to protect your data.