Receive your JavaScript security report

More no-brainers

5 tips for a secure use of JavaScript libraries

JavaScript libraries are very popular in modern websites. Besides the advantages, there are some risks associated with the use of these libraries. A little research shows that external JavaScript libraries in 1 out of 5 cases make the website more vulnerable. In one case it presumably even introduced malware. What are the risks of using JavaScript libraries, and how can those be addressed?

Tips for safe use of JavaScript libraries

The following controls are recommended for the safe use of open-source JavaScript libraries. In conjunction, it offers remediation for the risks that have been described above.

  • 1. Implement version management for JavaScript libraries as part of patch management. Make sure that always the latest version is used, or at least a version that does not contain public known vulnerabilities. An excellent tool for this is retire.js.
  • 2. Don’t use external library servers, but rather copy the JavaScript libraries to the server of the website that needs it. This way, the availability and reliability of the JavaScript library are identical to those of the website where it is used and there is no dependence on third parties.
  • 3. If external JavaScript libraries are used, periodically check the security of the remote library servers. Avoid library servers that appear on a malware blacklist. In addition, check the contents of the JavaScript library by using checksums such as MD5 and SHA.
  • 4. On a regular basis, check if your website is referring to external libraries. This informs you if someone injected links to malicious external library providers.
  • 5. Minimize the probability of XSS occurring, regardless of the library version that is used. The vulnerabilities are usually caused by insufficient input validation in JavaScript functions, resulting in the processing of HTML code where the script expects plain text. The XSS-risk is minimized by validating the input before the JavaScript function of the library is invoked. This control requires website developers to have security knowledge.

Background

A JavaScript library is a collection of JavaScript functions that is located in one or more scripts. Many of these libraries are open-source. The libraries accelerate the development of web sites, but is it safe to use them? In this article, we take a closer look at the risks of JavaScript libraries and on the necessary measures. JQuery is a common JavaScript library and is used here as an example to assess the risks.

JQuery makes it easier to create dynamic websites with advances functions, such as retrieving data from a web page or editing data in the browser. It’s also often part of the styling of websites, usually as a component of another package such as WordPress. My own observation from 20.000 websites is that jQuery is used in 1 out of 10 websites. This number is in line with statistics from Built With, which in addition states that more than 43 million websites use jQuery. Of the top websites, 3 out of 4 are using jQuery.

What are the vulnerabilities?

Many vulnerabilities in software are published on the internet. In jQuery, there is only a small number of publicly known vulnerabilities. The descriptions of the vulnerabilities can be found on the CVE database and on retire.js. Retire.js is a vulnerability checker for JavaScript libraries. For better understanding, the vulnerabilities are listed in the following table.

Public known vulnerabilities of jQuery

What are the risks?

The risks related to the use of standard JavaScript libraries are discussed here. Per risk, jQuery is used to add some real-world calculations of its occurrence. The possible countermeasures are mentioned as well.

Risk 1. The library version is outdated and contains vulnerabilities

Older versions of JavaScript libraries often contain vulnerabilities. These are scripts that run on the client’s browser; therefore, the vulnerabilities mostly concern Cross- Site Scripting (XSS). Once published, the vulnerability is usually resolved in the next release of the library.

JQuery has several known vulnerabilities, quoted earlier. When looking at the versions of jQuery in use, it is striking how diverse that is. Some versions are very popular; sometimes even versions of years ago. This is shown in the figure below. Of particular importance are versions older than 1.6.3: These versions are the most vulnerable.

Market share of the various jQuery versions
Figure 1. Market share of each version of jQuery, as a percentage of the websites that run jQuery (2016). Source: Built With (blue) and Internet-Security-Scan (brown). The red frame indicates where the oldest, most vulnerable versions are.

The figure shows that a significant proportion of the sites is using an outdated version of jQuery. Consequently, these sites are vulnerable to XSS. Thirteen percent (13%) of the jQuery libraries in use is over 5 years old and includes multiple Cross- Site Scripting vulnerabilities! Notice that the distribution of versions is odd. One would expect the bars to be highest for the newest versions, but that is clearly not the case.

The solution is to make version control of JavaScript libraries part of patch management. Patch management is usually in place for software platforms, servers and middleware, but JavaScript libraries are often out of scope.

Another generic solution that reduces the risk of old libraries is to make sure that the chances of XSS are minimal. The majority of vulnerabilities is due to insufficient input validation in JavaScript functions, so that HTML code is accepted as input where the function expects it to be clean text. Validating input before calling JavaScript functions from the library reduces the risk of XSS. This requires website developers to have knowledge of security.

Risk 2. The external JavaScript library is on a vulnerable server

Some websites do not serve JavaScript libraries from their own server, but instead refer to external sources for these libraries. Often these are Content Distribution Networks, Google API servers or the original source of the library. If the external library server is vulnerable, this poses a risk to the web application.

Looking at jQuery in terms of external hosting, we see the following:

  • Of the 1613 websites with a jQuery script, there are 189 hosted outside their own DNS domain
  • Of the 189 external libraries, there are 77 at google.com (google axis)
  • Of the 189, there are 37 at jquery.com
  • There are 75 other external servers

The conclusion is that 12% of the websites that use JavaScript libraries redirect the browser to remote library servers. For the reliability of the libraries, the website depends on the security of the remote library servers. After all, if the external library server is not secure, there is a chance that it will be hacked. The risk is that on the hacked server, the JavaScript libraries are replaced with malicious variants, which are subsequently used by the website. The result is that visitors will experience XSS attacks and/or might be made part of a botnet.

How secure are the remote library servers anyway? A quick check with Internet-Security-Scan on the 75 "other" remote servers reveals that:

  • 13 remote library servers contain one or more security no-brainers (mainly SSL configuration issues).
  • 2 external library servers have a bad reputation (a.o. blacklisted for malware distribution)

External hosted libraries of jQuery
Figure 2. The locations of externally hosted jQuery libraries. Of these, 7% appears to be on vulnerable servers.

Thus, of the websites that use an external jQuery library (other than Google and jQuery), 1/5 relies on a library-server whose security configuration is not flawless. That is 1 % of the total amount of web sites that use jQuery. The probability of a vulnerable server being compromised is bigger than that of a well-secured server. This demonstrates the risk of being dependent on third parties.

The safest and easiest solution is placing the JavaScript library on the website itself, instead of using external library servers. In that case, the availability and reliability of the library are identical to these of the site where it is used.

When for some reason it’s still required to use an external library, select a content provider that has an adequate security-level and re-check it’s security periodically. In particular, avoid library servers that are registered on a malware blacklist.

Risk 3. The external library contains malware

The external JavaScript library can contain malware. The consequence is that this malware is distributed across all the website visitors. It could for example copy passwords or data. The question if a library is indeed malware can be answered by calculating and verifying a checksum of the library. Any deviation in a file, no matter how tiny, results in a different and unique checksum. By validating the checksum it can be detected if a library has been tampered with.

In the above jQuery research case, two external library servers were found that had a bad reputation. One of the two provided a jQuery -library with a deviating hash. This was detected easily and turned out to be an obfuscated JavaScript file, see screenshot below.

Comparison of Javascript scripts
Figure 3. Comparison of a jQuery script on a server with a bad reputation (left) with the original (right). The left one is obfuscated, the right one is minimized.

JQuery is usually not obfuscated but only minimized, because that poses less performance requirements to the client. The fact that obfuscation is done on a server with a bad reputation is suspicious. Is this library ​​obfuscated with the purpose of hiding any malicious adjustments? For me, this is sufficient reason to avoid this library server.

The solution for validating the content of the JavaScript library is the use of checksums, such as MD5 or SHA-256. Although MD5 is not strong enough for keys or passwords anymore, it is still useful for detecting malicious files. This checksum validation should be repeated on a regular basis, to prevent the external library from injecting the website with scripts that launch XSS-attacks.

Risk 4. A website is inadvertently using an external library

A common attack to WordPress and Joomla! Is injecting the sites with links to fake jQuery libraries. A prerequisite is that the attacker has write-privileges on the website. To this end, WordPress, Drupal and Joomla! websites are constantly bombarded with login attempts. After a successful login as an administrator, the links to malicious JavaScript libraries are added to the HTML code of the website. Hackers also inject links to their external fake libraries by spamming posts on a forum. This requires fewer privileges but is also more restricted in its possibilities.

This type of attack once was detected, where the name ‘/js/jquery.min.php’ was used for the external library. It has nothing to do with jQuery itself; it only takes advantage of the fact that a link to a jQuery library will not raise suspicion. These fake libraries are subsequently retrieved and ran by the browser. This is an example of how malware can be distributed. See this blog for more details on this specific attack.

The solution to this problem is to conduct a regular check to see if any website is using external libraries. When the baseline rule is that exotic external library-servers should not be used, it's easy to spot an incident if a scan does report links to external libraries.