Communications of the ACM

that JavaScript libraries do not introduce any new attack vectors into the websites where they are used.

At the time of our research, there was no single “authoritative” public database of JavaScript vulnerabilities. We manually searched the Open Source Vulnerability Database (OSVDB), the National Vulnerability Database (NVD), public bug trackers, GitHub comments, blog posts, and the list of vulnerabilities detected by Retire.js ( https://retirejs.github.io/retire. js/) to gather metadata about vulnerable and fixed versions for the 11 popular libraries shown in Figure 1. As a result, given the name of one of these 11 libraries and a specific release version, we can say whether we know about any publicly disclosed vulnerability—but there are likely more vulnerabilities that we do not know about. Thus, what we report here should be seen as a lower bound.

Library Detection

Collecting vulnerability metadata manually was feasible because we restricted ourselves to 11 of the most popular libraries. For detection of libraries used on websites, however, an automated approach was needed. At first, detecting a library on a website does not sound too complicated: check how the library file is called in the official distribution, such as jquery- 3. 2. 1.js, and look for that name in the URLs loaded by websites. Unfortunately, it’s rarely that easy. Web developers can rename files, and they do. Using this simple strategy rather than the more complex detection methodology would miss 44% of all URLs containing the Modernizr library, for example. This is not acceptable.

Our approach uses a combination of
static and dynamic methods. The static
method is a slight improvement over
the name-based approach: instead of
detecting library files by their name, we
detect them by the file hash. This re-
quired a comprehensive catalogue of li-
brary file hashes, compiled from down-
load links found on the libraries’
websites, and on JavaScript CDNs (con-
tent delivery networks) maintained by
Google, Microsoft, and Yandex, as well
as the community-based CDNs jsDe-
livr, cdnjs, and OSS CDN. Some librar-
ies, such as Bootstrap and jQuery,
maintain their own branded CDNs,
which were included as well. All ver-
sions and variants of each library were
as XSS (cross-site scripting), which al-
lows an attacker to inject malicious
code (or HTML) into a website. In par-
ticular, if a JavaScript library accepts
input from the user and does a poor
job validating it, an XSS vulnerability
might creep in, and all websites using
this library could become vulnerable.

As an example, consider jQuery’s $() function. It has different behavior depending on which type of argument is passed: if the argument is a string containing a CSS (Cascading Style Sheets) selector, the function searches the DOM (Document Object Model) tree for corresponding elements and returns references to them; if the input string contains HTML, the function creates the corresponding elements and returns the references. As a consequence, developers who pass improperly sanitized input to this function may inadvertently allow attackers to inject code into the page even though the programmer’s intent is to select an existing element. While this API design places convenience over security considerations, and the implications could be better highlighted in the documentation, it does not automatically constitute a vulnerability in the library.

In older versions of jQuery, however, the $() function’s leniency in parsing string parameters could lead to complications by misleading developers to believe, for example, that any string beginning with would be interpreted as a selector and could be safe to pass to the function, as #test selects the element with the identifier test. Yet, jQuery considered parameters containing an HTML <tag> anywhere in the string as HTML ( https://bugs.jquery.com/tick- et/9521), so that a parameter such as #<img src=/ onerror=alert( 1)> would lead to code execution rather than a selection. This behavior was considered a vulnerability and fixed.

Other vulnerabilities in JavaScript libraries include cases where libraries fail to sanitize inputs that are expected to be pure text but are passed to eval() or document.write() internally, which could cause them to be executed as script or rendered as markup. Attackers could exploit these capabilities to steal data from a user’s browsing session, initiate transactions on the user’s behalf, or place fake content on a website. Therefore, it is important