JavaScript libraries are very popular on modern websites. In addition to the benefits, using these libraries involves certain risks. A little research shows that external JavaScript libraries in 1 in 5 cases make the website more vulnerable. In one case, he probably even introduced malware. What are the risks of using JavaScript libraries and how can they be resolved?
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.
- Implement version management for JavaScript libraries as part of patch management. Make sure that the latest version is always used, or at least one that does not contain known public vulnerabilities. Retire.js is a great tool for this.
- Do not use external library servers, but instead copy the JavaScript libraries to the website server that needs them. In this way, the availability and reliability of the JavaScript library is identical to that of the website where it is used and there is no dependence on third parties.
- If external JavaScript libraries are used, periodically check the security of remote library servers. Avoid library servers that appear on a malware blacklist. In addition, verify the contents of the JavaScript library using checksums such as MD5 and SHA.
- Check regularly if your website references external libraries. This informs you if someone has injected links to malicious external library providers.
- Minimize the probability of XSS appearing, regardless of the library version used. The vulnerabilities are usually caused by insufficient input validation in JavaScript functions, which cause HTML code to be processed where the script expects plain text. The XSS risk is minimized by validating the input before calling the JavaScript function of the library. This check requires that website developers have security knowledge.
Background
A JavaScript library is a collection of JavaScript functions found in one or more scripts. Many of these libraries are open-source. Libraries speed up website development, but is it safe to use them? In this article, we take a closer look at the risks of JavaScript libraries and the measures required. JQuery is a common JavaScript library and is used here as an example for risk assessment.
JQuery makes it easy to create dynamic websites with advanced features, such as retrieving data from a web page or modifying data in the browser. This is also often part of the style of websites, usually as part of another package such as WordPress. My own observation from 20,000 websites is that jQuery is used in 1 in 10 websites. This number is consistent with statistics from Built With, which further indicates that more than 43 million websites use jQuery. Among the best websites, 3 out of 4 use jQuery.
What are the vulnerabilities?
Numerous vulnerabilities in software are published on the Internet. In jQuery, there are only a small number of vulnerabilities known to the public. 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 a better understanding, the vulnerabilities are listed in the following table.
What are the risks?
The risks of using standard JavaScript libraries are discussed here. By risk, jQuery is used to add real calculations of its occurrence. Possible countermeasures are also mentioned.
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 mainly relate to Cross-Site Scripting (XSS). Once published, the vulnerability is generally resolved in the next version of the library.
JQuery has several known vulnerabilities, mentioned above. When looking at the versions of jQuery in use, it is striking to see how diverse it is. Some versions are very popular; sometimes even versions of years ago. This is illustrated in the figure below. Versions prior to 1.6.3 are particularly important: these versions are the most vulnerable.
The solution is to integrate version control of JavaScript libraries into patch management. Patch management is generally in place for software platforms, servers, and middleware, but JavaScript libraries are often out of reach.
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 are due to insufficient input validation in JavaScript functions, so that HTML code is accepted as input where the function expects to be in clear text. Validating the input before calling JavaScript functions from the library reduces the risk of XSS. This requires that website developers 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 rather refer to external sources for these libraries. Often these are content distribution networks, Google API servers, or the library’s original source. 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 bottom line is that 12% of websites that use JavaScript libraries redirect the browser to remote library servers. For library reliability, the website depends on the security of remote library servers. After all, if the external library server is not secure, it may be hacked. The risk is that on the hacked server, the JavaScript libraries will be replaced by malicious variants, which are then used by the site. The result is that visitors will experience XSS attacks and / or be part of a botnet.
How secure are remote library servers? 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)
The safest and easiest solution is to place the JavaScript library on the website itself, instead of using external library servers. In this case, the availability and reliability of the library are identical to those of the site where it is used.
When for some reason it is still necessary to use an external library, select a content provider with an adequate level of security and check its security regularly. In particular, avoid library servers registered on a malware blacklist.
Risk 3. The external library contains malware
The external JavaScript library may contain malware. The consequence is that this malware is distributed to all site visitors. For example, it could copy passwords or data. The question of whether a library is indeed malware can be resolved by calculating and verifying a library checksum. Any discrepancy in a file, however small, results in a different and unique checksum. By validating the checksum, it can be detected if a library has been tampered with.
The query is generally not obfuscated but only minimized, as this places less performance requirements on the client. The fact that the obfuscation is done on a bad reputation server is suspect. Is this library obscured in order to hide malicious adjustments? For me, this is reason enough to avoid this library server.
The solution to validate the content of the JavaScript library is the use of checksums, such as MD5 or SHA-256. Although MD5 is no longer strong enough for keys or passwords, it is still useful for detecting malicious files. This checksum validation must be repeated regularly, 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 with WordPress and Joomla! Injects sites to bogus 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 connection attempts. After successfully logging in as an administrator, links to malicious JavaScript libraries are added to the website’s HTML code. Hackers also inject links to their fake external libraries by sending spam messages to a forum. This requires fewer privileges but is also more limited in its possibilities.
This type of attack was detected once, where the name ‘/js/jquery.min.php was used for the external library. It has nothing to do with jQuery itself; it only benefits from the fact that a link to a jQuery library will not raise suspicion. These bogus libraries are then retrieved and executed by the browser. This is an example of how malware can be distributed. Check out this blog for more details on this specific attack.
The solution to this problem is to do a regular check to see if a website is using external libraries. When the rule of thumb is that exotic external library servers should not be used, it is easy to spot a problem if a scan reports links to external libraries.
Leave A Comment