PolyKill: A Journey to Understand Javascript Risk

Oct 23, 2024

Earlier this year, in a major supply chain attack, hundreds of thousands of websites using the Polyfill.io JavaScript were compromised after the domain was acquired by a foreign adversary. The adversary began serving malicious JavaScript to websites who had embedded cdn.polyfill.io in their pages (+340K .gov and .com domains were affected). This script targeted mobile users, redirecting them to scam sites based on factors like user agent and geographic location. Despite initial warnings from the original creator of the polyfill service, the attack went unnoticed for months.


This incident underscores the persistent risk posed by unmonitored JavaScript running on websites. Existing client-side protection tools are often inadequate, as they tend to be blackbox systems, overly noisy, and typically tied to a Web Application Firewall (WAF) integration, which are not always equipped to handle the complexity of JavaScript analysis. LeakSignal sought out to come up with a solution to address this gap, it would:


  • Easily inventory and track JavaScript loading on every page load.
  • Analyze the URLs for risk from known public sources (malware, block lists, etc.).
  • Analyze the history to see if the domain has been transferred recently.
  • Understand the 3rd party breach history of the script owner.
  • Perform an AI-based script runtime analysis to understand any sensitive data that could be captured or sent to 3rd parties.

Community Response

The LeakSignal team has been actively engaging with the broader cybersecurity community over the past few months, responding to thousands of requests for vulnerability scans related to the polyfill attack. We reached out to affected government agencies and top cybersecurity leaders, warning them about the attack and offering assistance through video calls and email discussions. By collaborating with these organizations and site owners, we worked to develop a solution that addresses the community’s specific concerns. 

Understanding the Third-Party Javascript Attack Surface

Let’s break down how websites are vulnerable today. Third party JavaScripts (JS) can be integrated in three primary ways:


1. Direct Script Tag Inclusion: Adding a script tag directly, via tag manager or other CMS capability. Each time a page loads, the third-party script is downloaded by the user’s browser and executed.

2. Dynamic Loading: Appended to the page dynamically by other trusted (first party) scripts.

3. Bundled with First-Party Code: Packaging up the third party script into a first-party JS file. The CI/CD process downloads the third party script and refreshes it on every build. These files are often scanned for vulnerabilities before deployment with some type of Dynamic Application Security Testing (DAST) tooling like Snyk, Veracode and others. Once packaged and minified, these files are served under the same domain as the first party host URL and continue running across every page load.


The attack surface regarding JavaScript execution is fairly complex and dynamic. The risk could be from the sale of an open source project, compromise of the third party infrastructure, or transferring ownership of a domain (as we saw with the polyfill.io attack). 


Once the polyfill.io attack had been executed, threat actors selectively targeted users based on factors like user agent, IP address, and geolocation. This allowed the adversary to exploit a significant source of traffic while evading detection from existing tools and manual checks.

The Problem: JavaScript Monitoring

Most website and application owners lack visibility into the data third-party scripts collect, the services they’re calling, or even the hosting environments of these services. They often don’t know if these third parties are collecting Personally Identifiable Information (PII), their compliance with regulations, or how much user data they’ve already collected. 


Even with many JavaScript monitoring solutions on the market, most failed to detect the Polyfill.io attack because they miss the bigger picture of understanding JavaScript risk before something bad happens. The scale and complexity of the attack required a community-wide response for effective detection. Instead of relying solely on vendor-managed tools, we believe JavaScript risk analysis should be a crowdsourced, public endeavor—similar to ad block lists, but focused on preventing malicious scripts.

Introducing PolyKill JS: A PowerfulMonitoring Solution

To address these challenges, we created polykill JS, an open-source JavaScript analysis solution that can be easily added to any website. Polykill JS waits for the page to fully load and then passively inventories:


  • JavaScript Files
  • Top level domains in use
  • XHR requests
  • Beacons
 

Here’s how it works: The benign inventory of JS files is asynchronously sent to the Polykill Risk API, which downloads each script behind the scenes and runs an analysis to determine the following:

 

1. Is the URL malicious (e.g. polyfill.io)? : We cross-reference several external safe URL apis and our own data source, which is updated to prevent attacks like the one involving polyfill.io

2. Is the URL blocked by ad blockers?: If so, we determine why it’s being blocked and if that poses a risk.

3. What is the risk associated with the 3rd party hosting the script? We analyze the breach history of the hosting domain along with any known risks.

 4. Can the script, in its current state, collect PII?  We determine how the third-party is storing and using data it collects.

The analysis results are stored on polykill.io, where users can access detailed reports similar to Google Analytics.

If this is interesting to you, we’ll be releasing the JavaScript for inclusion in your website on a first come first serve basis. Please submit your email here.


For cases where it is not possible to add the polykill snippet of JavaScript to your website or if you’d like to sample the reporting that will be provided, you can run a manual report on any web application using the free Chrome extension here.

Looking Ahead: Compliance and Security

As we prepare for PCI DSS 4.0, which goes into effect in March 2025, website owners that process payments must ensure compliance by understanding the inventory and risk associated with JavaScript on pages that collect PII and payment data.

 

By collaborating with the Polykill community and organizations like PCI and NIST, our goal is to provide transparency and actionable insights. By focusing on the power of community feedback, AI analysis, and compliance, Polykill JS aims to offer a simple, yet powerful tool to protect websites and their users from the evolving threats in the JavaScript ecosystem.