Understanding the Risks: Polyfill.io and Open-Source Vulnerabilities
Written on
Chapter 1: The Polyfill.io Incident
Recent discussions online have erupted regarding polyfill.io allegedly injecting harmful code into websites that utilized its CDN. This claim, which has gathered significant attention, is just the tip of the iceberg.
Photo by Max Bender on Unsplash
In February, the ownership of the GitHub repository and the associated download domain changed hands. The modifications didn't start this week; they began earlier.
To illustrate, we began encountering strange errors when users attempted to log in. The stack trace provided by Sentry was perplexing, as it pointed to code buried deep within the okta-react library. We had not upgraded our okta-react, okta-js, or Sentry libraries recently.
After a detailed examination using the debugger, I discovered that the Okta code was expecting to receive an object with iterable properties. At times, this object lacked the necessary properties to iterate over. Upon further investigation, it became clear that this object originated from code deep within the polyfill library.
I quickly removed the CDN link, which resolved the issue. Additionally, I initiated a ticket to eliminate other CDN links, including those for font-awesome and Google Analytics, and promptly shared a warning on LinkedIn.
As it stands, the polyfill library has been tampered with for several months. It’s unlikely that the malicious code injection just started recently. I regret not sharing this information earlier on other platforms, though I doubt it would have gained much attention.
I hadn’t anticipated that major websites, which many people rely on, would still be utilizing such outdated technology. The full extent of the impact caused by this malicious site’s unrestricted access over the past four months remains unclear. It is probable that many users have been affected in some way. It appears that malicious actors may have achieved their objectives before drawing attention to the breach by redirecting users to inappropriate sites.
How Did This Occur?
You might wonder how so many websites ended up linking to a compromised site. To grasp this, we need to reflect on web development practices from a decade ago. It often took years for standards to gain widespread acceptance across different browsers. Furthermore, many corporations had lengthy approval processes for updates. Consequently, developers frequently turned to polyfill libraries to bridge the gap, allowing them to code as if the standards were already implemented. The intention was to remove these polyfills once the standards became universally available.
However, this transition never materialized. There has never been a formal announcement declaring that “all features provided by polyfills are now fully supported by the majority of browsers.” More importantly, developers may forget or move on from projects, and sometimes these tasks simply fail to rise to the top of the priority list. In our case, there was an open ticket to remove CDN links, but it only surfaced a few weeks before our incident, and it wasn’t treated as urgent.
Fortunately, you don’t need polyfills anymore. We didn’t encounter any issues after removing them, suggesting you won’t require an extensive QA cycle for the same action. Notably, polyfill.io has now been taken down by its domain registrar, so if you were relying on it, it's time to conduct QA to ensure any subtle changes aren't causing issues.
Is All Open-Source Software Vulnerable?
This question can be quite complex, as the answer can vary based on usage.
The primary concern with the polyfill.io code was its direct linking via a script tag from a CDN (Content Delivery Network). This setup leaves you uncertain about what is executing on your site at any given moment. While modern browsers have enhanced security measures to guard against cross-site scripting, libraries that modify the window and document objects may not appear different.
Currently, it is less common for code to be delivered directly from a CDN, with exceptions like fonts. If you utilize open-source libraries via npm or yarn, you are less likely to face this specific vulnerability. However, you might run into situations where a maintainer grows weary of unpaid work and releases an update that breaks your code.
To mitigate this risk, always specify exact versions in your package.json instead of using approximate or compatible versions. Regularly check your lock file (package-lock.json or yarn.lock) to confirm that the library version on your server matches what has been tested locally. Since the library code is installed on your server during the build process, it resides in a location you control.
Although this method isn’t foolproof—there is a rare chance of overwriting package versions with new code—it is uncommon for legitimate maintainers to do so. For added security, consider hosting specific versions of libraries yourself, such as on Artifactory.
Moving Forward
This incident has served as a valuable lesson for all involved. It emphasizes the importance of coding defensively, adhering to best practices, and contemplating potential pitfalls before they arise.
Happy coding!
Chapter 2: Exploring the Dark Side of the Web
The first video titled "20 Strange & Disturbing Horror Stories" delves into unsettling tales that highlight the eerie side of the internet.
The second video, "The Hidden Webpage: Scary Stories Found on The Internet | Creepypasta," explores chilling narratives that emphasize the dangers lurking online.