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
A drawback of
detecting a library
by its hash is that
it cannot be
detected when
there is no
corresponding
reference file in
the catalogue.