- 4. Check on a regular basis if your website is referring to external libraries. This informs you if someone injected links to malicious external library providers.
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?
What are the risks?
Risk 1. The library version is outdated and contains vulnerabilities
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.
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.
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
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)
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.
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
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.
Risk 4. A website is inadvertently using an external library
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.