Imagine If… Hackers Had Found the Cloudflare CDNJS Vulnerability First

On July 17, the news broke that a major security issue was reported about the Cloudflare CDNJS service. A security researcher disclosed a way for hackers to modify scripts served by CDNJS, completely overtaking CDNJS and every library on it.

That’s a huge deal, considering that nearly 13% of all websites on the Internet use Cloudflare CDNJS. According to nerdydata.com, that equates to 1,109,778 sites including Forbes, Yelp and GitLab. Even if only 50% of this list is correct, more than half a million sites could have been affected, many of which you likely use to discover, shop and interact with brands online.

Cloudflare moved quickly to address the vulnerability and there is no indication that it was exploited. But while CDNJS and the huge number of sites that rely on it dodged a bullet, online businesses shouldn’t breathe a sigh of relief just yet.

The Cloudflare incident was a close call. While, luckily, there were no victims in this case, the CDNJS discovery is a stark reminder for online businesses to understand their risk and protect themselves from script vulnerabilities before it’s too late.

Why is the CDNJS vulnerability important?

Websites today are built from a collection of scripts and libraries, most of which are pulled in from open source JavaScript libraries and vendors. Industry research shows that up to 70% of the scripts on a typical website are third party.

In an effort to move quickly, developers may introduce third-party scripts without sufficient approval or security validation. Also called shadow code, this third-party code may be frequently changed by the vendor that wrote it without your knowledge, rendering any prior security tests meaningless. These scripts may then refer to additional scripts, which call yet another set of scripts, and so on. This introduces a veritable supply chain of first-, third- and nth-party scripts that hackers can exploit.

Since these third party scripts run on the client side, traditional security controls can’t provide complete visibility into what they are doing or how they change over time. If hackers do abuse this code — if they had overtaken CDNJS, for example — you wouldn’t have the ability to stop it. You may not even become aware of it in the first place.

The Risk of Third-Party Code

With so many websites relying on third-party code, the implications of a security breach are huge. In the case of CDNJS, cybercriminals had an open attack vector to replace every script in the library. This would have allowed them to:

• Read sensitive personal data
• Redirect personally identifiable information (PII) to an alternate server for sale on the dark web or use in ATO attacks
• Add fields to payment pages to collect additional information
• Steal assets, such as money and/or loyalty points
• Redirect shipment on products that a consumer does purchase

Although it looks like CDNJS ended well, online businesses can’t let their guard down. It’s time to build up your defenses and prepare for an attack — because another security vulnerability will inevitably emerge, and a malicious hacker might be the one who first discovers it this time around.

There will be a next time; the only questions are “when?” and “how big?” Without ongoing visibility and control of script activity on your site, you can’t protect yourself and your customers. Undetected security vulnerabilities are gold for cybercriminals — don’t let your site be the goldmine.

Safeguard Your Site

So the question remains: what exactly can you do to safeguard your application and your consumers’ data?

The first step to protect your business is to understand what your existing defenses can and cannot do. Take web application firewalls (WAFs). While they can help with most of the top-ten OWASP risks, they aren’t sufficient to guard against client side attacks.

Because third-party scripts run on clients’ browsers outside your server, you can’t rely on preset policies to block malicious activity. Third-party scripts are constantly being added, changed, or removed to meet ever-evolving website needs, and WAFs have no visibility or control into what’s happening on the client side.

You need to have a complete understanding of all your third-party code — something that 92% of website owners lack. But it’s not impossible to get there. Website Risk Analyzer, a free Chrome extension that quickly scans web application scripts for vulnerabilities and suspicious behavior, allows you to assess the security risks within your scripts in a matter of minutes. Only by maintaining continuous visibility into all client-side scripts can you prevent hackers from exploiting them.