The Risk of Third-Party JavaScript

JavaScript is an essential part of almost every website today – if you see an animation, it is probably JavaScript; if you watch a video, it is usually integrated into the page with JavaScript; and if you do some form of transaction on the site, that is likely also all controlled by JavaScript. 

In order to create and deliver this functionality, most websites contain hundreds of thousands of lines of code – code which has been created internally by the site owners and code which comes from third-party libraries. In fact, the average website today uses around 60 third-party libraries within their site, providing everything from analytic and telemetry tracking from large technology providers to small user interface tweaks from open source projects. 

A traditional development mindset 

Using third-party libraries is not a new concept when it comes to development – in fact, software has been created this way for decades. When creating software, it is simply not possible for organizations to produce every piece of functionality themselves in most instances as they do not have the time or resources. Instead, developers will use both commercial and open-source libraries to add functionality to their online properties.

While including third-party code certainly has its risks – for example, a rogue provider could have included some malware in its library – in most cases, there is a significant testing process which checks many things including security. Before releasing a product to customers, most developers will reach a point where they are satisfied with the general usability and no security issues exist. If any part of the code changes – for example, the third-party provider creates a new library – the developers would go through the test process again before delivering a new product to its customers. 

With modern web development, the same approach has been taken by allowing JavaScript libraries to be included to bring functionality. When creating website code, developers will add tags in order to signal to a web browser that it should download these additional libraries before attempting to display the website. When a user visits the website using their device’s web browser, the website downloads all required code and then displays the resulting page. 

Dynamic loading 

However, there is one significant difference between traditional development and website development which is in how these libraries are ultimately delivered to users. With traditional applications, third-party libraries are compiled into an end product at development and build time and packed into the resulting binaries. If the developer changes a library, they then need to create a new product for customers to use – basically, if a developer changes code, then the product which the customers are using does not change until they get a new build. 

 With websites, libraries are downloaded, usually from the library vendor, each time a page is requested. In this model, code can change often – with some vendors changing their libraries multiple times a day – and if an organization’s website includes such libraries, their users are running the current version of this code each time they visit. 

Organizations often do not know whether their third-party providers are secure 

Most organizations invest heavily in their security, with everything from IT protection to physical security, such as door passes. For example, a business is not likely to allow just anyone to have access to the database where their customer data is stored and they would have procedures in place to ensure that a rogue developer cannot add malware designed to steal customer passwords, credit card information or login details. 

The challenge is, however, that many of the technologies used on that same organization’s website would be sourced from third parties who may have no such security. While an analytic tracking library from a major search engine could be trusted, some libraries could be from open source projects created as part of a college computer science course or stored in a repository which many developers can access or change.

Cybercriminals realize the weakness in this approach and know how they can leverage unsecure libraries to obtain customer data and breach an organization. For example, an attacker could inject password scraping malware into one of the JavaScript libraries in use – when a customer uses the website to access their internet banking or shopping account, the attacker’s code would scrape their passwords as they are being entered in real time, allowing them to later access the customer’s account. 

The shocking aspect to all of this is that the attackers never need to breach an organization’s own servers in order to gain access to, for example, their customers’ bank accounts. They simply need to inject code into a poorly-secured open-source JavaScript library –  a library which is then downloaded by every customer. 

Preventing third-party JavaScript abuse 

The best way to prevent security issues resulting from third-party code is for organizations to deliver the third-party JavaScript from their own servers and only after conducting significant code reviews. This means that each time a library changes, there must be a process where the developers obtain the new library, check the code and add it to their own servers – which is extremely hard to do. 

Third-party JavaScript technologies can contain hundreds of thousands of lines of code and change often, which means doing a sufficient quality and security check process each time is beyond the resource of most organizations and ultimately not possible, leaving many to simply accept the risk. 

Ensighten can help 

Ensighten allows organizations to prevent attacks resulting from breached third-party JavaScript libraries by providing technology that allows a filter to be placed within a website. This ensures that any data accessed by code, whether first, third or even further down the website supply chain, can only be sent to trusted and approved destinations. Should a library contain password scraping malware, the malware would not only be blocked from stealing user data, but the organization would be alerted to its presence. 

Our technologists will work with organizations and identify areas of potential concern with no obligation, regardless of whether they use our technology or not. With online skimming and injection-based attacks in general being relatively unknown, we are happy to talk to businesses if for nothing more than to help educate them on the risks. 

Get in contact to book a demo and see our solution in action.