Analysing the Use of Outdated Javascript Libraries on the Web

Home , Angular (web framework), Echo (framework), JavaScript library

Updated in September 2017: Require valid versions for library detection throughout the paper. The vulnerability analysis already did so and remains identical. Modiﬁcations in Tables I, III and IV; Figures 4 and 7; Sections III-B, IV-B, IV-C, IV-F and IV-H. Additionally, highlight Ember’s security practices in Section V.

Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web

Tobias Lauinger, Abdelberi Chaabane, Sajjad Arshad, William Robertson, Christo Wilson and Engin Kirda Northeastern University {toby, 3abdou, arshad, wkr, cbw, ek}@ccs.neu.edu

Abstract—Web developers routinely rely on third-party Java- scripts or HTML into vulnerable websites via a crafted tag. As Script libraries such as jQuery to enhance the functionality of a result, it is of the utmost importance for websites to manage their sites. However, if not properly maintained, such dependen- library dependencies and, in particular, to update vulnerable cies can create attack vectors allowing a site to be compromised. libraries in a timely fashion. In this paper, we conduct the first comprehensive study of To date, security research has addressed a wide range of client-side JavaScript library usage and the resulting security client-side security issues in websites, including validation [30] implications across the Web. Using data from over 133 k websites, we show that 37 % of them include at least one library with a and XSS ([17], [36]), cross-site request forgery [4], and session known vulnerability; the time lag behind the newest release of fixation [34]. However, the use of vulnerable JavaScript libraries a library is measured in the order of years. In order to better by websites has not received nearly as much attention. In understand why websites use so many vulnerable or outdated 2014, a series of blog posts presented cursory measurements libraries, we track causal inclusion relationships and quantify highlighting that major websites included known vulnerable different scenarios. We observe sites including libraries in ad hoc libraries ([25], [26], [24]). These findings echo warnings from and often transitive ways, which can lead to different versions of other software ecosystems like Android [3], Java [32] and the same library being loaded into the same document at the same Windows [21], which show that vulnerable libraries continue time. Furthermore, we find that libraries included transitively, or to exist in the wild even when they are widely known to via ad and tracking code, are more likely to be vulnerable. This contain severe vulnerabilities. Given that JavaScript dependency demonstrates that not only website administrators, but also the dynamic architecture and developers of third-party services are management is relatively primitive and corresponding tools to blame for the Web’s poor state of library management. are not as well-established as in more mature ecosystems, these findings suggest that security issues caused by outdated The results of our work underline the need for more thorough JavaScript libraries on the Web may be widespread. approaches to dependency management, code maintenance and third-party code inclusion on the Web. In this paper, we conduct the first comprehensive study on the security implications of JavaScript library usage in websites. We seek to answer the following questions: I.INTRODUCTION The Web is arguably the most popular contemporary • Where do websites load JavaScript libraries from (i.e., programming platform. Although websites are relatively easy to first or third-party domains), and how frequently are create, they are often composed of heterogeneous components these domains used? such as database backends, content generation engines, multiple • How current are the libraries that websites are using, scripting languages and client-side code, and they need to deal and do they contain known vulnerabilities? with unsanitised inputs encoded in several different formats. • Are web developers intentionally including JavaScript Hence, it is no surprise that it is challenging to secure websites libraries, or are these dependencies caused by adver- because of the large attack surface they expose. tising and tracking code? • Are existing remediation strategies effective or widely One specific, significant attack surface are vulnerabilities used? related to client-side JavaScript, such as cross-site scripting (XSS) and advanced phishing. Crucially, modern websites often • Are there additional technical, methodological, or include popular third-party JavaScript libraries, and thus are at organisational changes that can improve the security risk of inheriting vulnerabilities contained in these libraries. For of websites with respect to JavaScript library usage? example, a 2013 XSS vulnerability in the jQuery [13] library Note that the focus of this paper is not measuring the security before version 1.6.3 allowed remote attackers to inject arbitrary state of specific JavaScript libraries. Rather, our goal (and primary contribution) is to empirically examine whether website Permission to freely reproduce all or part of this paper for noncommercial operators keep their libraries current and react to publicly purposes is granted provided that copies bear this notice and the full citation disclosed vulnerabilities. on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author Answering these questions necessitated solving three funda- (for reproduction of an entire paper only), and the author’s employer if the mental methodological challenges. First, there is no centralised paper was prepared within the scope of employment. repository of metadata pertaining to JavaScript libraries and NDSS ’17, 26 February - 1 March 2017, San Diego, CA, USA Copyright 2017 Internet Society, ISBN 1-1891562-46-0 their versions, release dates, and known vulnerabilities. To https://doi.org/10.14722/ndss.2017.23414 address this, we manually constructed a catalogue containing all “release” versions of 72 of the most popular open-source • We present results on the origins of vulnerable libraries, including detailed vulnerability information on a JavaScript library inclusions, which allows us to subset of 11 libraries. Second, web developers often modify contrast the security posture of website developers with JavaScript libraries by reformatting, restructuring or appending third-party modules such as WordPress, advertising or code, which makes it difficult to detect library usage in the tracking networks, and social media widgets. wild. We solve this problem through a combination of static • We show that a large number of websites include and dynamic analysis techniques. Third, to understand why JavaScript libraries in unexpected ways, such as mul- specific libraries are loaded by a given site, we need to track all tiple inclusions of different library versions into the of the causal relationships between page elements (e.g., script same document, which may impact their attack surface. s1 in frame f1 injects script s2 into frame f2). To solve this, • We find existing remediation strategies to be ineffective we developed a customised version of Chromium that records at mitigating the threats posed by vulnerable JavaScript detailed causality trees of page element creation relationships. libraries. For example, less than 3 % of websites could Using these tools, we crawled the Alexa Top 75 k websites fix all their vulnerable libraries by applying only patch- and a random sample of 75 k websites drawn from a snapshot level updates. Similarly, only 2 % of websites use the of the .com zone in May 2016. These two crawls allow us to version-aliasing services offered by JavaScript CDNs. compare and contrast JavaScript library usage between popular and unpopular websites. In total, we observed 11,141,726 inline II.BACKGROUND scripts and script file inclusions; 86.6 % of Alexa sites and JavaScript has allowed web developers to build highly inter- 65.4 % of .com sites used at least one well-known JavaScript active websites with sophisticated functionality. For example, library, with jQuery being the most popular by a large majority. communication and production-related online services such as Analysis of our dataset reveals many concerning facts Gmail and Office 365 make heavy use of JavaScript to create about JavaScript library management on today’s Web. More web-based applications comparable to their more traditional than a third of the websites in our Alexa crawl include at desktop counterparts. In this paper, we focus exclusively on least one vulnerable library version, and nearly 10 % include aspects of client-side JavaScript executed in a browser, not the two or more different vulnerable versions. From a per-library recent trend of using JavaScript for server-side programming. perspective, at least 36.7 % of jQuery, 40.1 % of Angular, 86.6 % of Handlebars, and 87.3 % of YUI inclusions use a vulnerable A. JavaScript Libraries version. Alarmingly, many sites continue to rely on libraries like YUI and SWFObject that are no longer maintained. In fact, In many cases, to make their lives easier, web developers the median website in our dataset is using a library version rely on functionality that is bundled in libraries. For example, 1,177 days older than the newest release, which explains why so jQuery [13] is a popular JavaScript library that makes HTML many vulnerable libraries tend to linger on the Web. Advertising, document traversal and manipulation, event handling, animation, tracking and social widget code can cause transitive library and AJAX much simpler and compatible across browsers. inclusions with a higher rate of vulnerability, suggesting that In the simplest case, a JavaScript library is a plain-text script these problems extend beyond individual website administrators containing code with reasonably well-defined functionality. The to providers of Web infrastructure and services. script has full access to the DOM that includes it; the concept of We also observe many websites exhibiting surprising namespaces does not exist in JavaScript, and everything that is behaviours with respect to JavaScript library inclusion. For created is by default global. More elaborate libraries use hacks example, 4.2 % of websites using jQuery in the Alexa crawl and conventions to protect the code against naming conflicts, include the same library version multiple times in the same and expose interfaces for retrieving meta-data such as the name document, and 10.9 % include multiple different versions of and version of the library. Over the course of this study, we jQuery into the same document. To our knowledge, ours found that JavaScript libraries overwhelmingly use the Semantic is the first study to make these observations, since existing Versioning [28] convention of major.minor.patch, such tools ([27], [20]) are unable to detect these anomalies. These as 1.0.1, where the major version component is increased for strange behaviours may have a negative impact on security as breaking changes, the minor component for new functionality, asynchronous loading leads to nondeterministic behaviour, and and the patch component for backwards-compatible bug fixes. it remains unclear which version will ultimately be used. To include a library into their website, developers typically Perhaps our most sobering finding is practical evidence that use the HTML tag and the JavaScript library ecosystem is complex, unorganised, and point to an externally-hosted version of the library or a copy minified quite “ad hoc” with respect to security. As of this writing, there on their own server. Library vendors often provide a are no reliable vulnerability databases, no security mailing lists version that has comments and whitespace removed and local for the most popular libraries, few or no details on security variables shortened to reduce the size of the file. Developers issues in release notes, and often, it is difficult to identify which can also concatenate multiple libraries into a single file, create versions of a library are affected by a reported vulnerability. custom builds of libraries, or use advanced minification features such as dead code removal. While custom minification builds Overall, our study makes the following contributions: are relatively common, more aggressive minification settings are rare in client-side JavaScript because they can break code [9]. • We conduct the first comprehensive study showing that a significant number of websites include vulnerable or CDNs. Many libraries are available on Content Distribution outdated JavaScript libraries. Networks (CDNs) for use by other websites. Google, Microsoft

2 TABLE I. THE 30 MOSTFREQUENTLIBRARIESINOUR ALEXA CRAWL and Yandex host libraries on their CDNs, some popular libraries (OUTOF 72 SUPPORTED LIBRARIES).VERSIONS: s TOTAL IN REFERENCE (e.g., Bootstrap and jQuery) offer their own CDNs, and some CATALOGUE FOR STATIC DETECTION; d DYNAMIC DETECTIONS OBSERVED community-based CDNs accept to host arbitrary open-source IN CRAWLS (SOMELIBRARIES/VERSIONS NOT SUPPORTED DYNAMICALLY). libraries. JavaScript CDNs enable caching of libraries across websites to increase performance. Another useful feature offered Versions Bower Wapp Use on Crawled Sites Library s d Rank % ALEXA COM by some CDNs is version aliasing. That is, when including a jQuery 66 64 1 42 % 83.9 % 61.1 % library, the developer may specify a version prefix instead of the jQuery-UI 46 46 13 7 % 23.5 % 8.0 % full version string, in which case the CDN returns the newest Modernizr 24 28 18 10 % 21.4 % 8.6 % available version with that prefix. When implemented correctly, Bootstrap 32 10 3 12.5 % 4.5 % jQuery-Migrate 7 0 11.3 % 10.7 % the patched version of a library will automatically be used on the Underscore 61 34 12 3 % 5.8 % 2.4 % website when it becomes available on the CDN. However, this SWFObject 2 1 3.7 % 2.4 % works only for security issues fixed in a backwards-compatible Moment 54 33 6 3.5 % 1.4 % RequireJS 62 40 3.4 % 2.3 % manner, and it conflicts with client-side security mechanisms jQuery-Form 14 0 2.7 % 3.4 % such as subresource integrity [37]. In addition, version aliasing Backbone 29 19 2 % 2.7 % 1.6 % Angular 110 78 2 2.4 % 1.6 % makes client-side caching of resources less efficient because it LoDash 77 57 26 2.4 % 2.5 % must be configured for shorter time spans, that is, hours instead jQuery-Tools 8 20 2.3 % 0.9 % of years. As a result, version aliasing is often discouraged [11]. jQuery-Fancybox 10 0 2.3 % 1.4 % GreenSock GSAP 45 45 2.2 % 2.8 % Handlebars 25 15 2.0 % 0.4 % Third Parties. Third-party modules such as advertising, Prototype 5 14 1.8 % 1.1 % trackers, social media or other widgets that are often embedded MooTools 27 24 3 % 1.5 % 1.4 % WebFont Loader 100 0 1.5 % 0.9 % in webpages typically implemented in JavaScript. Furthermore, jQuery-Cookie 8 0 21 1.4 % 0.2 % these scripts can also load libraries, possibly without the Hammer.js 26 14 1.2 % 0.4 % knowledge of the site maintainer. If not isolated in a frame, jQuery-Validation 13 0 1.1 % 0.6 % Mustache 29 21 1.1 % 0.9 % these libraries gain full privileges in the including site’s context. YUI 3 37 26 1.0 % 1.4 % Thus, even if a web developer keeps own library dependencies Velocity 55 15 0.9 % 0.2 % Script.aculo.us 5 12 0.8 % 0.4 % updated, outdated versions may still be included by badly Knockout 21 9 0.8 % 0.1 % maintained third-party content. Also, some JavaScript libraries Flexslider 11 0 0.6 % 0.4 % and many web frameworks contain their own copies of libraries React 41 23 28 0.5 % 1.6 % they depend on. Hence, web developers may unknowingly rely on software maintainers to update JavaScript libraries. HTML anywhere in the string as HTML [14], so that a parameter such as # B. Vulnerabilities in JavaScript Libraries would lead to code execution rather than a selection. This While JavaScript is the de-facto standard for developing behaviour was considered a vulnerability and fixed. client-side code on the Web, at the same time it is notorious Other vulnerabilities in JavaScript libraries include cases for security vulnerabilities. A common, lingering problem is where libraries do not sanitise inputs that are expected to be Cross-Site Scripting (XSS) [17], which allows an attacker to pure text, but are passed to eval() or document.write() inject malicious code (or HTML) into a website. In particular, internally, which could cause them to be executed as script if a JavaScript library accepts input from the user and does or rendered as markup, respectively. Attackers can use these not validate it, an XSS vulnerability might creep in, and all capabilities to steal data from a user’s browsing session, initiate websites using this library could become vulnerable. transactions on the user’s behalf, or place fake content on a As an example, consider the popular jQuery library and its website. Therefore, JavaScript libraries must not introduce any $() function, which is overloaded and has different behaviour attack vectors into the websites where they are used. depending on which type of argument is passed [15]: If a string containing a CSS selector is passed, the function searches the III.METHODOLOGY DOM tree for corresponding elements and returns references to Identifying client-side JavaScript libraries, finding out how them; if the input string contains HTML, the function creates they are loaded by a website, and determining whether they are the corresponding elements and returns the references. As a outdated or vulnerable requires a combination of techniques consequence, developers who pass improperly sanitised input and data sources. Challenges arise due to the lax JavaScript to this function may inadvertently allow attackers to inject language, the fragmented library ecosystem, and the complex code even though the developers’ original intent was only nature of modern websites. First, we need to collect metadata to select an existing element. While this API design places about popular JavaScript libraries, including a list of available convenience over security considerations and the implications versions, the corresponding release dates, code samples, and could be better highlighted in the documentation, it does not known vulnerabilities. Second, we must be able to determine if automatically constitute a vulnerability in the library. JavaScript code found in the wild is a known library. Third, we need to crawl websites while keeping track of causal resource In older versions of jQuery, however, the $() function’s le- inclusion relationships and match them with detected libraries. niency in parsing string parameters could lead to complications by misleading developers to believe, for instance, that any string A. Catalogueing JavaScript Libraries beginning with # would be interpreted as a selector and could be safe to pass to the function, as #test selects the element with In contrast to Maven’s Central Repository in the Java world, identifier test. Yet, jQuery considered parameters containing a JavaScript does not have a similarly popular repository of library

3 versioning and project dependency metadata. We must therefore 0 2 4 collect and correlate this data from various separate sources. 1 3 5 Angular (110) 1) Selecting Libraries: The initial construction of our meta- Backbone (29) data archive involves a certain amount of manual verification Dojo (72) work. Since there are thousands of JavaScript libraries (e.g., Ember (77) the community-based cdnjs.com hosts 2,379 projects as of Handlebars (25) August 2016), we focus our study on the most widely used jQuery (66) libraries because they are the most consequential. jQuery-Migrate (7) jQuery-Mobile (16) To select libraries, we leverage library popularity statistics jQuery-UI (46) provided by the JavaScript package manager Bower [6] and Mustache (29) the web technology survey Wappalyzer [38]. We extend this YUI 3 (37) list of popular libraries with all projects hosted on the public 0.0 0.2 0.4 0.6 0.8 1.0 CDNs operated by Google, Microsoft and Yandex. As we will Fraction of total versions show in Section IV-C, many websites rely on these commercial Fig. 1. Fraction of library versions with i distinct known vulnerabilities CDNs to host JavaScript libraries. We collected the data from each (represented by colours), out of the total library versions in parentheses. Bower, Wappalyzer, and the three CDNs in January 2016. Angular 1.2.0 has 5 known vulnerabilities and there are 110 versions overall. Due to various data availability requirements explained in detail in Section III-A5, we need to exclude certain libraries from our study. Overall, we support 72 libraries—18 out of the ajax.googleapis.com/ajax/libs/jquery/{version}/jquery.min.js. In Top 20 installed with Bower, 7 out of the Top 10 frameworks doing so, we make sure that we download all available variants identified on websites by Wappalyzer, 13 of the 14 libraries of a library file, including the full development variant and the hosted by Google, 12 of the 18 libraries hosted by Microsoft, minified production variant without whitespace or comments. and all 11 libraries hosted by Yandex. Table I shows a subset When comparing files downloaded from official websites of 30 libraries in our catalogue as well as their rank on Bower and different CDNs, we noticed that even the same version and their market share according to Wappalyzer. Although our and variant (e.g., minified) of a library may sometimes differ catalogue appears to cover a sparse set of the libraries on between sources. We observed additional whitespace, removal Bower, many of the missing ranks belong to submodules of of comments, or the likely use of a different minifier or minifier popular libraries (e.g., rank 5 is Angular Mocks). According to setting, especially when the library’s developers do not provide a Wappalyzer, we cover 73 % of the most popular libraries. minified version. This observation highlights the importance of 2) Extracting Versioning Information: Our next step is collecting ground-truth JavaScript library samples from as many compiling a complete list of library versions along with official and semi-official sources as possible. Therefore, we use their release dates. After unsuccessful experiments with file official websites as well as dedicated CDNs (Bootstrap CDN timestamps and available-since dates on the libraries’ official and jQuery CDN), commercial CDNs (Google, Microsoft, and websites and CDNs, we determined that GitHub was the most Yandex), and open source CDNs (jsDelivr, cdnjs and OssCDN). reliable source for this kind of information. Nearly all of the In total, we collect 81,027 JavaScript files. We analyse open source libraries in our seed lists are hosted on GitHub the sizes of the “main” files of each library in our dataset and tag the source code of their releases, allowing us to extract (that is, we exclude files such as plug-ins that cannot be timestamps and version identifiers from the tags. In naming used stand-alone), and find that Script.aculo.us 1.9.0 is the their releases, they typically follow a major.minor.patch smallest at 996 bytes (minified). After accounting for duplicates version numbering scheme, which makes it straightforward to and discarding files smaller than 996 bytes (to reduce the identify tags pertaining to releases and ignore all other tags, likelihood of false positives due to shared ancillary resources including “alpha,” “beta” and “release candidate” versions that such as configuration files, localisations and plug-ins), our final are not meant to be used in production. As shown in Table I, catalogue includes 19,099 distinct files. popular libraries like Angular and jQuery have up to 110 and 66 distinct versions in our catalogue, respectively. However, 4) Identifying Vulnerabilities: The last step towards building half of the libraries have fewer than 26 versions. our catalogue is aggregating vulnerability information for our 72 JavaScript libraries. Unfortunately, there is no centralised 3) Obtaining Reference Files: Some methods of library database of vulnerabilities in JavaScript libraries; instead, we detection require us to have access to code samples for each manually compile vulnerability information from the Open version of a library. We gather library code from two sources: Source Vulnerability Database (OSVDB), the National Vulnera- the official website of each library, and from CDNs. For the bility Database (NVD), public bug trackers, GitHub comments, official websites, we manually download all available library blog posts, and the vulnerabilities detected by Retire.js [27]. versions. However, some official websites do not provide copies of old library versions, or they only provide copies of a subset Overall, we are able to obtain systematically documented of versions. In contrast, CDNs typically do host comprehensive details of vulnerabilities for 11 of the JavaScript libraries in collections of old library versions in order to not break websites our catalogue. In some cases, the documentation for a given that depend on older versions. We utilise the API of one such flaw specifies an affected range of versions, in which case we CDN, jsDelivr, to automatically discover all available versions consider all library versions within the range to be vulnerable. of libraries on five supported CDNs. For the remaining CDNs, In other cases, when a flaw is identified in a specific version v we construct download link templates manually, such as https:// of a library, we consider all versions ≤ v to be vulnerable.

4 Figure 1 shows details of the 11 libraries with vulnerability global variable that can be detected at runtime. Furthermore, information. For each library, we show the total number of most libraries in our catalogue contain a variable or method versions in our catalogue as well as the fraction of versions that returns the version of the library. As an illustration, the with i distinct known vulnerabilities. The worst offender is following snippet of JavaScript code detects jQuery: 1.2.0 Angular , which contains 5 vulnerabilities. Overall, we 1 v a r jq = window.jQuery || window.$ || window.$jq || see that 28.3 %, 6.7 %, and 6.1 % of these library versions window . $ j ; contain one, two, or three known vulnerabilities, respectively. 2 i f(jq && jq.fn) { 3 r e t u r n jq.fn.jquery || null;// version(if known) 5) Limitations: Although we have expended a great deal of 4 } else{ effort constructing our catalogue of JavaScript libraries, it is 5 r e t u r n false;// jQuery not found impacted by several limitations. First, by choosing GitHub for 6 } versioning and release date information, we need to exclude a Line 1 extracts jQuery’s global variable, and line 3 returns the small number of libraries that have few or no releases tagged on version number if it exists in its fn.jquery attribute. Note GitHub or do so in an apparently inconsistent way (e.g., multiple that in order to prevent false positives, we check for the global successive releases tagged on the same day). Furthermore, we variable and that the fn attribute exists. Later on, we discard all cannot include closed-source libraries such as Google Maps, detections with missing or syntactically invalid version strings. advertising and tracking libraries like Google Analytics, and While this dynamic methodology detects libraries even if the social widgets since they typically do not publish version source code has been (lightly) modified, it relies on the version information. Fortunately, the vast majority of such libraries are attribute to be present. Hence, we can dynamically detect only hosted by their creators at a single, non-versioned URL (e.g., 39 out of the 72 libraries, and for some, we do not detect https://www.google-analytics.com/analytics.js), meaning that (typically older) versions lacking the version string. Table I all clients automatically include the latest version of the library. compares the versions detected dynamically in our crawls d Second, our catalogue may miss some revisions of libraries to our static reference catalogue s . Version coverage is often if the author chose to patch the code and not increment the similar; dynamic outperforms static when CDNs are incomplete. version number. Similarly, we may miss revisions if they are Limitations: Our two detection techniques represent a best- denoted using non-standard notation, such as special suffixes, effort approach to identifying JavaScript libraries in the wild. four-part version numbers, etc., and we may not possess However, there are cases where both techniques can fail. For any code samples for a version of a library if it cannot be example, heavily modified libraries will not match our file downloaded from the developer website or a supported CDN. hashes nor will they match the dynamic signatures. Furthermore, Third, our library vulnerability assessments are based solely we rely on the correctness of our information sources, i.e., that on publicly available documentation. We make no attempts to CDNs contain the version of a library that they claim, and that discover new vulnerabilities, or to quantify the exploitability libraries export the correct version string and do not attempt to of libraries as used on websites, for both practical and ethical conceal their presence. Effectively, these limitations mean that reasons. Thus, although a website may include a vulnerable our measurement results should be viewed as lower bounds. library, this does not necessarily imply that the website is exploitable. Furthermore, libraries differ in their release cycles, C. Data Collection attack surfaces, functionality, and public scrutiny with respect A central contribution of our work is to analyse not only to vulnerabilities. Thus, we do not claim to provide comparable whether outdated libraries are being used, but why this may coverage of vulnerabilities for each library in our catalogue. be the case. This implies that detecting whether a library exists in a window or frame is not enough; we must also B. Library Identification detect if it was loaded by another script. To model causal inclusion relationships of resources in websites, we introduce Identifying an unknown file as a specific version of a the theoretical concept of causality trees and implement it JavaScript library is challenging because these libraries are text, in a modern browser. We integrate our two library detection which gives web developers, development tools and network methods into this modified browser environment and use it to software the ability to modify them, e.g., by adding or removing collect data about the usage of JavaScript libraries on the Web. features, concatenating multiple libraries into a single file, or tampering with comments. To reliably detect as many libraries Causality Trees: The goal of a causality tree is to represent as possible, we use two complementary techniques. These the causal element creation relationships that occur during techniques are conceptually similar to those used by the Library the loading and execution of a dynamic website in a modern Detector Chrome extension [20] and Retire.js. browser. A causality tree contains a directed edge A → B if and only if element A causes element B to load. More Static Detection: We compute the file hashes of all observed specifically, the elements we model include scripts, images JavaScript code and compare them to the 19,099 reference and other media content, stylesheets, and embedded HTML hashes in our catalogue. File hashing enables us to identify all documents. A relationship exists whenever an element creates cases where libraries are used “as-is.” another element (e.g., a script creates an iframe) or changes an existing element’s URL (e.g., a script changes the URL of an Dynamic Detection: During the crawl, we detect the iframe or redirects the main document), which is equivalent to presence of libraries in the browser by fingerprinting the creating a new element with a different URL. JavaScript runtime environment and by relying on libraries to identify themselves. Specifically, modern libraries typically While the nodes in a causality tree correspond to nodes make themselves available to the environment by means of a in the website’s DOM, their structure is entirely unrelated to

5 Ad Frame w/ Scripts Chrome Debugging Protocol [8] to minimise the necessity for Ad Script Inline Script brittle browser source code modifications. The Chrome Debugging Protocol provides programmatic access to the browser and allows clients to attach to open windows, inspect network traffic, and interact with the JavaScript Included Scripts Root Frame environment and the DOM tree loaded in the window. Two prominent uses of this API are the Chrome Developer Tools (an Fig. 2. Example causality tree. HTML and JavaScript front-end to the protocol) and Selenium’s WebDriver interface to remotely control Chrome. the hierarchical DOM tree. Rather, nodes in the causality tree At a high level, we generate causality trees by observing are snapshots of elements in the DOM tree at specific points resource requests through the network view of the debugging in time, and may appear multiple times if the DOM elements protocol. Note that this view includes resources not actually are repeatedly modified. For instance, if a script creates an loaded over the network, e.g., inline URL schemas such as iframe with URL U1 and later changes the URL to U2, the data: or javascript:. We disable all forms of caching corresponding script node in the causality tree will have two to observe even duplicate resource inclusions within the same document nodes as its children, corresponding to URLs U1 frame, which are otherwise handled through an in-memory and U2, but referring to the same HTML element. cache. For each loaded resource, the protocol allows us to Similarly, the predecessor of a node in the causality tree is not identify the frame in which the resource is located as well necessarily a predecessor of the corresponding HTML element as the initiating script, where applicable. Similarly, we utilise in the DOM tree; they may even be located in two different protocol methods to be notified of script generation events and HTML documents, such as when a script appends an element store the source code of both inline and URL-based JavaScript. to a document in a different frame. (This includes source code from attribute-based event handlers and string evaluation, which we both model as inline script Figure 2 shows a synthetic example of a causality tree. nodes.) We store a log of all relevant events during the crawl The large black circle is the document root (main document), and assemble the causality trees in a post-processing step. filled circles are scripts, squares are HTML documents (e.g., embedded in frames or corresponding to a new main document Integration of Library Detection: Hash-based detection of if there is a top-level redirect), and empty circles are other re- libraries is relatively straight-forward to integrate with our sources (e.g., images). Edges denote “created by” relationships; crawler; we simply compute the source code hashes of all for example, in Figure 2 the main document included the grey script nodes in the causality trees and look them up in our script, which in turn included the blue script. Dashed lines reference catalogue during post-processing. around nodes denote inline scripts, while solid lines denote Integrating dynamic library detection is more challenging— scripts included from an URL. Thick outlines denote that a out of the box, existing detection methods can only detect resource was included from a known ad network, tracker, or whether a JavaScript context (window or frame) contains a social widget (see below for more details). library or not, but in general this information is not sufficient to properly label the correct script node in the causality tree. The colour of nodes in Figure 2 denotes which document The Chrome Debugging Protocol allows us to link a method attached to they are in the DOM: grey corresponds to resources executed in a JavaScript context to the script that contains its attached to the main document, while we assign one of four implementation; thus, once we hold a reference to a JavaScript colours to each further document in frames. Document squares library object (such as jq in the example from Section III-B), contain the colour of their parent location in the DOM, and we dynamically enumerate its instance methods and use an their own assigned colour. Resources created by a script in arbitrary one of them to identify the implementing script. one frame can be attached to a document in another frame, as shown by the grey script which has a blue child in Figure 2, Another challenge in dynamically detecting libraries during i.e., the blue script is a child of the blue document in the DOM. the crawl is that we need to inject the detection code into each frame of a website, since each frame has its own JavaScript Figure 12 shows the causality tree of mercantil.com, scope and may contain independent library instances. This is with images and other irrelevant node types omitted for clarity. further complicated by the fact that modern websites are quite It includes three clearly visible social media widgets: <a href="/tags/Twitter/" rel="tag">Twitter</a>, dynamic and an ad frame, for instance, may quickly navigate Facebook, and LinkedIn. Note that the web developer embedded to a different URL, which causes any library previously loaded code provided by the social networks into the main document, in the frame to be unloaded or replaced. Lastly, we observe which in turn initialises each widget and creates one or more that many websites include multiple copies of the same library, frames for their contents. We also see that the causality tree including different versions of the same library (refer to our includes multiple copies of jQuery in the main document, which analysis in Section IV-G for details). Typically, only one library we will discuss in detail in Section IV-G. instance can exist in each context because the more recently loaded instance replaces the previous global reference. Implementation of Causality Trees: Our definition of causality trees is related to the concepts previously used to In order to be able to study these phenomena in detail and analyse malicious JavaScript inclusions [1] and cookie matching also address the other aforementioned detection challenges, we between online ad exchanges [5], but it differs in the details. Our inject the detection code into each frame and execute it every implementation is independent from the aforementioned works 4 seconds. Note that it would not be feasible from a performance and uses a different technological approach by building on the point of view to execute the detection code after each script</p><p>6 creation event since websites routinely contain thousands of version of each loaded library, which enables us to assess the script nodes (see Section IV-B). accuracy of the dynamic detection. To detect cases of inclusions that we may miss due to Overall, we observe that the dynamic detection code is the four-second detection interval, we additionally execute the able to identify the exact name and version of 79.2 % of the dynamic detection code post hoc on all scripts found during libraries, as well as the name (but not the version) of 18.6 % the crawl. This execution is done in an individual Node.js of the libraries. Only 2 % of libraries fail to be identified (i.e., environment with a fake DOM tree. This offline detection were false negatives). We manually examine the libraries that step cannot fully replace in-browser detections, however, since are only detected by name, and find that the vast majority are some libraries such as jQuery UI have code or environment older versions that do not include a variable or method that prerequisites that cause the offline detection to fail. returns the library version. Of course, 100 % of these libraries can be detected based on their file hashes, which reinforces the Annotation of Ads, Trackers and Widgets: To further clarify importance of using multiple techniques to identify libraries. the provenance of scripts we observe in our crawl, we aim to determine whether they are related to known advertising, Static Detection: To investigate the efficacy of library tracking, or social widget code. We achieve this by injecting detection using file hashes, we conduct a second controlled a customised version of the AdBlock browser extension into experiment: we randomly select from our crawled data 415 each frame. Our version of AdBlock flags content but permits unique scripts that the dynamic detection code classifies as it to load, and we verified that our customised version remains being jQuery, and attempt to detect them based on their file undetected by common ad-block detection scripts. We use hashes. In this case, we are treating the output of the dynamic EasyList and EasyPrivacy to identify advertising and tracking detection method as ground truth. content, and Fanboy’s Social Blocking List to detect social Overall, we observe that only 15.4 % of the libraries can network widgets. For our analysis, we label an element in be identified as jQuery based on their file hash. Although this the causality tree as ad/tracker/widget-related whenever the is a low detection rate, the result also matches our expectation corresponding element or any parent in the DOM tree is labeled that developers often deploy customised versions of libraries. by AdBlock. Additionally, we propagate these labels downwards For example, 90 % of the jQuery libraries that we fail to detect to all children of the labelled node in the causality tree. via file hashing contain fewer than 150 line break characters, Crawl Parameters: To gain a representative view of whereas non-minified copies of jQuery from our catalogue JavaScript library usage on the Web, we collected two different contain more than 1900. This strongly suggests that the unique datasets. First, we crawled the Alexa Top 75 k domains, which scripts are custom-minified versions of jQuery. represent websites popular with users. Second, we crawled Hypothetical “Name-in-URL” Detection: For the last 75 k domains randomly sampled from a snapshot of the .com validation step, we consider a simple library detection heuristic. zone, that is, a random sample of all websites with a .com The heuristic flags a script file as jQuery, for instance, whenever address, which we expect to be dominated by less popular the string “jquery” appears in the URL of the script. To evaluate websites. We conducted the two crawls in May 2016 from IP the accuracy of this heuristic, we extract from our ALEXA crawl addresses in a /24 range in the US. We observe ∼5 % and the set of script URLs that contain “jquery,” and the URLs of ∼17.2 % failure rates in ALEXA and COM, leaving us with scripts detected as jQuery by our dynamic and static methods. data from 71,217 and 62,086 unique domains, respectively. Out of these URLs, 22.3 % contain “jquery” and are also Failures were due to timeouts and unresolvable domains, which detected as the library; 69 % are flagged only by the heuristic, is expected especially for COM since the zone file contains and 8.8 % are detected only by our dynamic and static methods. domains that may not have an active website. The heuristic appears to cause a large number of false positives To preserve the fidelity of our data collection, our crawler is due to scripts named “jquery” without containing the library, based on Chromium and includes support for Flash. We disable and it also seems to suffer from false negatives due to scripts various security mechanisms such as malware and phishing that contain jQuery but have an unrelated name. filters. We only crawl the homepage of each visited site due We validate this finding by manually examining 50 scripts to the presence of many sites that thwart deeper traversal by from each of the two set differences. The scripts in the requiring log-ins. While visiting a page, the crawler scrolls detection-only sample appear to contain additional code such downwards to trigger loading of any dynamic content. As we as application code or other libraries. Only one of these scripts found page-loaded events to be unreliable, our crawler remains does not contain jQuery but Zepto.js, an alternative to jQuery on each page for a fixed delay of 60 seconds before clearing that is partially compatible and also defines the characteristic its entire state, restarting, and then proceeding to the next site. $.fn variable. On the other hand, none of the scripts in the heuristic-only sample can be confirmed as the library; nearly D. Validation all of them contain plug-ins for jQuery but not the library itself. As the final step in our methodology, we validate that our The results for the Modernizr library, which does not have static and dynamic detection methods work in practice. an equivalent to jQuery’s extensive plug-in ecosystem, confirm this trend. The overlap between heuristic and detection is 55.3 % Dynamic Detection: To investigate the efficacy of our of URLs, heuristic-only 0.8 %, and detection-only 44 %—the dynamic detection code, we conduct a controlled experiment: simple heuristic misses many Modernizr files renamed by we load each of the reference libraries in our catalogue into developers. These results underline the need for more robust Node.js, one at a time, and attempt to detect each file with detection techniques such as our dynamic and static methods; the dynamic detection method. Intuitively, we know the exact we do not use the heuristic in our analysis.</p><p>7 1.0 1.0 1.0 Internal External 0.8 Inline 0.8 0.8</p><p>0.6 0.6 0.6</p><p>0.4 0.4 0.4 CDF (Alexa sites) CDF (Alexa sites) CDF (Alexa sites) Inline 0.2 0.2 External 0.2 Internal Vulnerable All All 0.0 0.0 0.0 100 101 102 103 104 105 0 2 4 6 8 10 12 14 0 2 4 6 8 10 12 14 # scripts # detected libraries # detected libraries</p><p>Fig. 3. Distribution of JavaScript inclusion type Fig. 4. Distribution of library inclusion type fre- Fig. 5. Distribution of vulnerable library count frequency per site in ALEXA. quency per site in ALEXA. versus overall library count per site in ALEXA.</p><p>1.0 1.0 1.0 Internal External 0.8 Inline 0.8 0.8</p><p>0.6 0.6 0.6</p><p>0.4 0.4 0.4 CDF (com sites) CDF (com sites) CDF (com sites) Inline 0.2 0.2 External 0.2 Internal Vulnerable All All 0.0 0.0 0.0 100 101 102 103 104 105 0 2 4 6 8 10 12 14 0 2 4 6 8 10 12 14 # scripts # detected libraries # detected libraries</p><p>Fig. 6. Distribution of JavaScript inclusion type Fig. 7. Distribution of library inclusion type fre- Fig. 8. Distribution of vulnerable library count frequency per site in COM. quency per site in COM. versus overall library count per site in COM.</p><p>IV. ANALYSIS Since paths correspond to causal relationships, intuitively this means that the inclusion of a node could have been influenced In this section, we analyse the data from our web crawls. by up to 438 predecessors. In both crawls, images tend to First, we present a general overview of the dataset by drilling appear further up in the causality trees at a median depth of 1, down into the causality trees, overall JavaScript inclusion that is, at least half of them are directly included in the main statistics, and vulnerable JavaScript library inclusions. Next, we document, whereas documents tend to appear further down examine risk factors for sites that include vulnerable libraries, at a median depth of 2, which indicates that they are more and the age of vulnerable libraries (i.e., relative to the latest frequently dynamically generated. release of each library). Finally, we examine unexpected, duplicate library inclusions in websites, and investigate whether common remediations practices are useful and used in practice. B. General JavaScript Statistics Scripts are the most common node type in our causality A. Causality Trees trees; 97 % of ALEXA sites and 83.6 % of COM sites contain We begin our analysis by measuring the complexity of the JavaScript. The most common script type are inline scripts, websites in our crawls. The median causality tree in ALEXA which includes script code embedded as text in a <script> contains 133 nodes (p95: 425, max: 19,508) whereas it is tag, any code in attribute-based event handlers (such as the 38 nodes (p95: 298, max: 25,485) in COM, indicating that onclick attribute), and any code evaluated from strings using ALEXA contains a larger share of more complex websites. methods such as eval(). The causality trees from the ALEXA Similarly, ALEXA and COM contain a median of 52 and and COM crawls contain a median of 24 and 9 inline scripts, 14 image nodes, 44 and 16 script nodes, and 4 and 2 document respectively, with 13.6 % and 6.7 % of the sites having hundreds nodes per causality tree, respectively. 95 % of frames in both of inline scripts—the maximum observed was 19 K and 25 K. crawls show only one or two documents during the 60 s of When looking at URL-based script inclusions, we distin- our crawl, whereas a few cycle through larger numbers of guish between internal scripts, that is, code hosted on the documents (max: 12 for ALEXA and 32 for COM). same domain as the website (or a subdomain of the website), The median depth of the causality trees (defined as the and all other scripts that we call external. Figures 3 and 6 length of the longest path from the root to a leaf) is 4 inclusions depict the distribution of script inclusion types for ALEXA and (p95: 9, max: 438) in ALEXA and 3 (p95: 8, max: 62) in COM. COM, respectively. About 91.7 % of all ALEXA sites include</p><p>8 TABLE II. EXTERNAL JAVASCRIPT:TOP 10 MARKETSHARE. TABLE IV. INCLUSIONTYPESOFDETECTEDLIBRARIES: LOADEDFROM SORTED BY ALEXA; DATA OMITTED FOR HOSTS NOT PART OF THE TOP 10. INLINE/INTERNAL/EXTERNALSCRIPT & INCLUSIONS (OFANYTYPE) DUE TOAD/TRACKER/WIDGETCODE.GREYEDOUTIF <100 INCLUSIONS; Hostname ALEXA COM OMITTEDIF <10. LIBRARIESCOUNTEDATMOSTONCEPERSITE. www.google.com 11.5 % www.google-analytics.com 9.5 % 9.4 % ALEXA COM ak2.imgaft.com 5.6 % Included From Ad/Tr./ Included From Ad/Tr./ ajax.googleapis.com 3.1 % 3.9 % Library Inl. Int. Ext. Widget Inl. Int. Ext. Widget pagead2.googlesyndication.com 2.9 % 1.5 % connect.facebook.net 2.8 % 1.5 % jQuery 2.7 58.8 38.6 3.4 2.9 29.5 67.6 25.6 www.googletagmanager.com 2.4 % Modernizr 3.0 65.4 31.6 12.2 1.4 38.2 60.4 3.5 www.googletagservices.com 2.1 % Bootstrap 1.7 69.9 28.4 0.3 0.5 49.2 50.3 3.5 partner.googleadservices.com 2.0 % SWFObject 4.4 34.2 61.4 42.4 0.8 13.7 85.5 4.5 www.googleadservices.com 2.0 % RequireJS 2.6 46.6 50.8 8.4 3.9 95.7 6.4 platform.twitter.com 1.8 % 1.2 % Angular 2.2 56.8 41.0 3.8 5.7 94.2 5.3 <a href="/tags/API/" rel="tag">apis</a>.google.com 1.5 % 1.3 % LoDash 0.7 48.3 51.0 10.6 7.2 92.7 6.7 maps.googleapis.com 1.3 % GreenSock 13.6 46.0 40.4 30.5 20.3 22.1 57.6 3.7 s.ytimg.com 1.2 %</p><p> made by all our techniques, but exclude detections where the TABLE III. DETECTED JS LIBRARIES:TOP 10 MARKETSHARE. SORTED BY ALEXA; DATA OMITTED FOR HOSTS NOT PART OF THE TOP 10. version of the library is unknown. Overall, we detect at least one of our 72 target libraries on 86.6 % of all ALEXA sites and Hostname ALEXA COM 65.4 % of all sites in COM. Table I lists the 30 libraries that ak2.imgaft.com 18.3 % appear on most sites in ALEXA. We also list the percentage ajax.googleapis.com 17.6 % 12.7 % of sites in COM that include the same libraries; however, for code.jquery.com 3.5 % 3.1 % static.hugedomains.com 2.8 % clarity we omit two libraries (both below 0.5 %) that are part static.parastorage.com 2.3 % of the Top 30 in COM but not in ALEXA. jQuery is by far the img.sedoparking.com 1.6 % most popular library, which we find on 83.9 % of the ALEXA img4.wsimg.com 1.5 % cdnjs.cloudflare.com 2.1 % 1.4 % sites and 61.1 % of the COM sites. SWFObject, a library used static.squarespace.com 1.3 % to include <a href="/tags/Adobe_Flash/" rel="tag">Adobe Flash</a> content, is ranked seventh (3.7 %) and s0.2mdn.net 1.4 % tenth (2.4 %) despite being discontinued [33] since 2013. On ivid-cdn.adhigh.net 1.2 % maxcdn.bootstrapcdn.com 0.9 % the other hand, several relatively well-known libraries such as s0.wp.com 0.9 % D3, Dojo and Leaflet appear below the Top 30 in both crawls. cdn10.trafficjunky.net 0.4 % netdna.bootstrapcdn.com 0.4 % We also observe that the market share for these libraries is ajax.aspnetcdn.com 0.3 % generally consistent with the data reported by Wappalyzer. dsms0mj1bbhn4.cloudfront.net 0.3 % Figures 4 and 7 show the distribution of detected libraries with respect to their inclusion type (i.e., inline, internal, and at least one external script, which is consistent with the 88.5 % external) in the two crawls. We detect libraries in inline script Nikiforakis et al. found for the Alexa Top 10 k [22]. The median on 4.1 % of all ALEXA sites (and 2.8 % of COM sites), which occurs when library code is copy-pasted into a <script> tag number of internal scripts is 4 per site in ALEXA (0 in COM) and the maximum is 224 (134). Externally-hosted script appears directly embedded in HTML, or when a script is generated by evaluating a string. For instance, we observe that a version of more prevalent with a median of 9 in ALEXA (max: 202) and Dojo loads additional components by making an asynchronous 2 in COM (max: 172); 6.3 % of sites in ALEXA, and 4.8 % in request and passing the response to eval(). We detect internal COM, include 30 or more external scripts. However, we note that we likely underestimate the fraction of internal scripts and external inclusions in 62.0 % and 41.1 % of all sites with because our domain name-based heuristic cannot infer that two an overall median of two different libraries per site in ALEXA domains may be under the same administrative control when (COM: internal libraries on 21.4 % of sites, external on 48.7 %, one is not a subdomain of the other. In both crawls, the median with a median of one library per site). inclusion depth of an internal script node is 1, i.e., directly Table III contains the most frequent hosts serving detected included by the main document, whereas the median depth of JavaScript libraries. Unsurprisingly, JavaScript CDNs are well an external script node is 2, suggesting indirect inclusions. represented (six in the Top 10 of ALEXA and three in the Each site includes scripts from a median of 5 external hosts Top 10 of COM); they were all used to build our catalogue of library reference files. Between 13 % and 18 % of all non- in ALEXA (2 in COM) with a maximum of 50 (45). Table II lists the hostnames most frequently included by <script> inline JavaScript library inclusions are loaded from Google’s tags (counting each hostname at most once per site to reduce CDN. Perhaps illustrating the “long tail” nature of the COM bias through multiple inclusions). At least 5 of the Top 10 crawl, we observe that several web hosting and domain parking companies are represented in the Top 10 library sources of in ALEXA are related to advertising, especially Google’s ad platforms. This agrees with prior work that has found Google’s COM (note that we did not group subdomains; e.g., there are wsimg.com Web advertising presence to be nearly ubiquitous ([10], [7]). multiple other subdomains of below the Top 10). Table IV lists the percentage of inline, internal, and external C. General Library Statistics inclusions for a selection of detected libraries. While the majority of inclusions in ALEXA come from internally-hosted Next, we narrow our analysis to focus just on JavaScript sources (i.e., the website’s own domain), most inclusions libraries from our catalogue. We use the union of detections are external in COM. About 7.3 % of all sites in ALEXA</p><p>9 0.9 3500 0.8 3000 At least one library 0.7 Vulnerable 2500 0.6 0.5 2000</p><p>0.4 1500 0.3 0.8 0.6 1000</p><p>Fraction of sites in Top x 0.2 0.4</p><p>0.2 500 0.1 Days behind newest release (max.) 0.0 0.0 0 200 400 600 800 1000 0 0 10000 20000 30000 40000 50000 Governm.Financial Malicious Parked Adult Random Top x sites Fig. 9. Fraction of websites with detected vulnerable inclusions in the Fig. 10. Box plot of each website’s maximum lag behind the newest release ALEXA Top x, and fraction of websites with at least one detected library for of each detected library, broken down into site categories and a random sample comparison. Vulnerable libraries can be found on 26 % of Top 500 websites. of 10,000 websites (ALEXA). Governmental sites are longest behind.</p><p>(16.0 % in COM) contain at least one library inclusion that is not maintained any more). These numbers illustrate that is causally related to ad, tracker or widget code; SWFObject inclusions of known vulnerable versions can make up even a and GreenSock are relatively often included by such code. majority of all inclusions of a library. However, we caution that these numbers are not suitable for comparing the relative D. Vulnerable Libraries vulnerabilities of different libraries (see Section III-A5). We now move on to answering our research questions, starting with how many websites become potentially vulnerable E. Risk Factors for Vulnerability due to including a library version with known vulnerabilities. So far, we have examined whether sites are potentially Figure 5 shows the distribution of total and vulnerable vulnerable, that is, whether they include one or more known libraries per ALEXA website. Overall, we find that 37.8 % vulnerable libraries. In the following, we turn to how libraries of sites use at least one library version that we know to be are included by sites and whether we can identify any factors vulnerable, and 9.7 % use two or more different vulnerable indicating a higher fraction of vulnerable inclusions. library versions (COM in Figure 8: 37.4 % and 4.1 %). When we look at how the library is being hosted, inline To better understand how website popularity is correlated inclusions of jQuery have a clearly higher fraction of vulnerable with vulnerable libraries, we plot in Figure 9 the percentage versions than internally or externally hosted copies. The of vulnerable ALEXA websites according to their Alexa ranks. situation is similar when focusing on the parent node of a Highly-ranked websites tend to be less likely to include library, that is, the document or script that caused the library vulnerable libraries, but they are also less likely to include to be included. For most libraries, direct inclusions by the any detected library at all. Towards the lower ranks, both main document are less likely to be vulnerable than indirect curves increase at a similar pace until they stabilise. While inclusions such as through an intermediate script or in a frame. only 21 % of the Top 100 websites use a known vulnerable library, this percentage increases to 32.2 % in the Top 1 k As an example for web applications, we briefly survey before it stabilises in the Top 5 k and remains around the library use related to WordPress. We consider a library to be overall average of 37.8 % for all 75 k websites. This indicates used by WordPress if the URL of either the library or its that even relatively large websites (albeit not the largest ones) next parent in the causality tree contains /wp-content/; have a vulnerability rate comparable to the average of the COM an inclusion is unrelated if neither condition holds. For all dataset, which is dominated by smaller sites. libraries, WordPress-related inclusions appear to be slightly more up-to-date than unrelated inclusions. When grouping ALEXA according to the McAfee Smart- Filter web categorisation [19], we find that financial and On the other hand, library inclusions by ad, widget or tracker governmental websites rank last with 52 % and 50 % vulnerable code appear to be more vulnerable than unrelated inclusions. sites, respectively. Malicious websites (e.g., spam) have the While the difference is relatively small for jQuery in ALEXA, same proportion as the full dataset, while parked and adult the vulnerability rate of jQuery associated with ad, widget sites are the least vulnerable with 24 % and 19 %, respectively. or tracker code in COM—89 %—is almost double the rate of unrelated inclusions. We speculate that this may be due to the Table V shows the percentage of vulnerable copies for 5 out use of less reputable ad networks or widgets on the smaller of the 11 JavaScript libraries in our catalogue with vulnerability sites in COM as opposed to the larger sites in ALEXA. data. In ALEXA, 36.7 % of jQuery inclusions are known vulnerable, when at most one inclusion of a specific library We note that the factors above are relatively coarse and version is counted per site. Angular has 40.1 % vulnerable the effects are sometimes opposite for different libraries. We inclusions, Handlebars has 86.6 %, and YUI 3 has 87.3 % (it suggest further investigation into the underlying causes.</p><p>10 TABLE V. VULNERABLEFRACTIONOFINCLUSIONSPERLIBRARY, COUNTING AT MOST ONE LIBRARY-VERSION PAIR PER SITE.CONFIGURATIONS WITH LESSTHAN 100 VULNERABLEINCLUSIONSGRAYEDOUT; OMITTEDIFLESSTHAN 10 TOTAL INCLUSIONS AFTER FILTER.</p><p>(a) ALEXA (b) COM Inclusion Filter jQuery jQ-UI Angular Handlebars YUI 3 Inclusion Filter jQuery jQ-UI Angular Handlebars YUI 3 All Inclusions 36.7 % 33.7 % 40.1 % 86.6 % 87.3 % All Inclusions 55.4 % 37.3 % 38.7 % 87.5 % 13.7 % Internal 38.1 % 33.0 % 37.1 % 84.6 % 92.8 % Internal 41.6 % 28.1 % 45.8 % 100.0 % 68.8 % External 34.8 % 35.5 % 48.2 % 88.6 % 83.8 % External 62.7 % 42.7 % 38.4 % 85.4 % 12.6 % Inline 54.8 % 30.7 % 20.0 % 100.0 %- Inline 89.9 % 25.6 %--- Internal Parent 37.1 % 33.7 % 40.6 % 85.3 % 91.3 % Internal Parent 59.7 % 37.0 % 78.2 % 94.2 % 47.9 % External Parent 32.6 % 33.8 % 41.8 % 96.4 % 92.2 % External Parent 45.9 % 38.0 % 20.7 % 84.1 % 68.9 % Inline Parent 47.6 % 35.2 % 25.6 % 83.7 % 79.6 % Inline Parent 79.8 % 48.9 %-- 1.0 % Direct Incl. in Root 36.4 % 33.5 % 40.1 % 85.2 % 90.4 % Direct Incl. in Root 42.6 % 36.2 % 41.3 % 88.7 % 50.4 % Indirect Inclusion 41.0 % 35.6 % 43.2 % 92.3 % 87.1 % Indirect Inclusion 77.5 % 44.5 % 30.8 % 86.4 % 7.5 % WordPress 29.2 % 14.4 % 23.5 % 77.3 %- WordPress 41.6 % 20.4 % 25.0 % 70.3 %- Non-WordPress 36.8 % 34.2 % 40.7 % 86.8 % 87.3 % Non-WordPress 55.6 % 38.6 % 38.9 % 90.7 % 13.7 % Ad/Widget/Tracker 38.1 % 39.8 % 23.5 % 96.9 % 98.2 % Ad/Widget/Tracker 89.0 % 31.6 % 19.2 %- 55.0 % No Ad/Widget/Tracker 36.7 % 33.6 % 40.8 % 86.5 % 84.1 % No Ad/Widget/Tracker 45.5 % 37.3 % 39.6 % 87.3 % 12.7 %</p><p>TABLE VI. DAYSBETWEENRELEASEOFUSEDVERSIONANDNEWEST LEXA AVAILABLE LIBRARY VERSION (MEDIANOVERINCLUSIONS).SHOWN inclusion in A uses a version 491 days older than the SEPARATELY FOR VULNERABLE AND NON-VULNERABLEINCLUSIONS newest D3 release. For Mootools, the lag is 1,417 days. WHERE AVAILABLE, OR (CENTRED) FORALLINCLUSIONSOTHERWISE. GREYEDOUTWHENLESSTHAN 100 INCLUSIONS OBSERVED. To characterise lag from a per-site point of view, we calculate the maximum lag of all inclusions on each site and find ALEXA COM that 61.4 % of ALEXA sites are at least one patch version behind Library Vuln. Non-V. Vuln. Non-V. on one of their included libraries (COM: 46.2 %). Similarly, the jQuery 1476 705 2243 705 median ALEXA site uses a version released 1,177 days (COM: jQuery-Migrate 1105 1024 1105 1024 1,476 days) before the newest available release of the library. jQuery-Mobile 49 122 Bootstrap 304 389 Finally, we plot this lag according to the category of ALEXA Angular 657 234 489 287 th th th Handlebars 6870 687 57 sites in Figure 10. Each candlestick shows the 5 , 25 , 50 , th th Prototype 1772 1772 75 , and 95 percentiles, respectively. We observe that both MooTools 1417 1417 governmental and financial websites are the longest behind YUI 3 393 140 393 140 Raphael 1491 1491 current releases with a median lag of 1,293 and 1,239 days, D3 491 139 respectively. Similar to per-category vulnerability rates, parked and adult websites exhibit values better than the average. In summary, these results demonstrate that the majority of F. Relative Age of Libraries web developers are working with library versions released a When websites include outdated libraries, an interesting long time ago. We observe median lags measured in years, question is how far they are behind more current versions of the suggesting that web developers rarely update their library libraries. We begin by looking at how far sites are behind the dependencies once they have deployed a site. most recent patch-level releases of libraries. Patch-level releases are usually (though not always) backwards-compatible. In G. Duplicate Inclusions ALEXA, we observe that non-vulnerable inclusions of Angular lag behind by a median of five versions, whereas the median While analysing the use of JavaScript libraries on websites, is seven versions for vulnerable inclusions. we noticed that libraries are often used in unexpected ways. We discuss some examples using jQuery as a case study. About When looking at the number of days between the release 20.7 % of the websites including jQuery in ALEXA (17.2 % in date of the included version and the release date of the newest COM) do so two or more times. While it may be necessary to available library version overall, the lag for Angular is 398 days include a library multiple times within different documents from for all inclusions, 657 days for vulnerable inclusions, and different origins, 4.2 % of websites using jQuery in ALEXA 234 days for non-vulnerable inclusions. While this may suggest include the same version of the library two or more times that there is a relationship between higher lag and vulnerability into the same document (5.1 % in COM), and 10.9 % (5.7 %) of a site, we note that the lag is also tied to the availability of include two or more different versions of jQuery into the newer versions—if no update is available, the lag is zero yet same document. Since jQuery registers itself as a window- the used version could be vulnerable. For instance, 6.7 % of global variable, unless special steps are taken only the last all (16.6 % of vulnerable) Angular inclusions in ALEXA use loaded and executed instance can be used by client code. For the latest available release in their respective patch branch, but asynchronously included instances, it may even be difficult to remain vulnerable as the branch contains no fixed version. predict which version will prevail in the end. With this caveat in mind, Table VI shows the median lag (in Figure 11 shows the causality tree of ms.gov, the site with days) behind the most recently released version of each library. the highest number of identical jQuery inclusions in a single We observe significant variations. For instance, the median D3 document. Only one instance (version 2.2.2) is included</p><p>11 jq u e r y</p><p>Twitter ry p e ra u t q ts j o o b ery jqu uery jq ry jque uery jquery jq modernizr, yepnope jquery ry jquery jque jquery jquery jquery</p><p> bootstrap</p><p>SWFObject jquery jquery-ui Facebook</p><p> ry e y r y u e r jq u e LinkedIn jq u jq</p><p>Fig. 11. Causality tree for ms.gov, showing multiple jQuery inclusions in Fig. 12. Causality tree for mercantil.com with multiple jQuery inclusions, a single document. One instance is referenced in the main HTML page; all two libraries concatenated into one file (Modernizr and Yepnope), and complex others are included transitively by other scripts. element relationships in social media widgets (Twitter, Facebook and LinkedIn). directly in the source code of the main HTML page; all twelve with a more recent major or minor version, which might other jQuery inclusions (of version 2.2.0) are injected by necessitate additional code changes due to incompatibilities. various self-hosted scripts in quick succession. Version Aliasing. Some JavaScript CDNs support version In contrast, the inclusions of four different jQuery versions aliasing, where the developer may specify only a prefix of on mercantil.com (Figure 12) are all referenced directly in the requested library version and the CDN will automatically the main page’s source code, some of them directly adjacent to return the latest available version with that prefix. In theory, each other. While we can only speculate why these cases occur, version aliasing appears to be a robust strategy for developers at least some of them may be related to server-side templating, to easily keep their library dependencies up-to-date. We scan or the combination of independently developed components our crawl for library inclusions with URLs of a CDN, and into a single document. Indeed, we have observed cases where detect version aliasing whenever (1) the version given in the a <a href="/tags/Web_application/" rel="tag">web application</a> (e.g., a WordPress plug-in) that bundled URL has only one or two components, such as 1.2, and (2) its own version of a library was integrated into a page that the library version detected by the static or dynamic method already contained a separate copy of the same library. Since is greater than the prefix extended with zeros, such as 1.2.3 duplicate inclusions of a library do not necessarily break any instead of 1.2.0. In ALEXA (and COM), we detect 1,489 functionality, we suspect that many web developers may not (914) confirmed instances of version aliasing, counting at most be aware that they include a library multiple times, and even one per library on each site. Overall, however, the frequency of less that the duplicate inclusion may be potentially vulnerable. version aliasing is very small—only around 1.2 % of all sites that include jQuery use version aliasing. H. Remediations Except for one, all instances of aliasing refer to Google’s From a remediation perspective, the picture painted by CDN, with jQuery being the most frequent library. One one our data is bleak. We observe that only very small fraction hand, 47.2 % (37.9 %) of jQuery inclusions with aliasing are of potentially vulnerable sites (2.8 % in ALEXA, 1.6 % in avoiding a vulnerability, i.e., the inclusions point to a branch COM) could become free of vulnerabilities by applying patch- that has a known vulnerability, but the issue is addressed by the level updates, i.e., an update of the least significant version latest version. On the other hand, while version aliasing may component, such as from 1.2.3 to 1.2.4, which would seem like a good way to automatically avoid vulnerabilities, generally be expected to be backwards compatible. The vast Google recently discontinued this service, citing caching issues majority of sites would need to install at least one library and “lack of compatibility between even minor versions” [11].</p><p>12 V. DISCUSSION or social media widget code have a higher rate of vulnerability than other inclusions. Such components are often hosted on Our research has shown that even though patches may be third-party servers and loaded dynamically through client- available, vulnerable JavaScript libraries are in widespread use side JavaScript. Additional libraries loaded at runtime by on the Web. In the following, we discuss approaches that we these components do not appear in the website’s codebase, believe could improve the situation. and web developers may be unaware that they are indirectly Dependency Management: Before website developers can including vulnerable code into their website. Similarly, dynamic update potentially vulnerable libraries that they are using, they inclusions of libraries by third-party components may explain must be aware of which libraries they are using. Instead of some of the same-document duplicate inclusions that we noticed. manually copying library files or CDN links into their codebase, In addition to keeping their library dependencies up to date, developers should consider more systematic approaches to developers of web services meant to be included into other dependency management. Bower [6] and the more server- websites could avoid replacing an existing library instance oriented Node Package Manager [23] allow developers to by using a methodology similar to ours to test whether the declare external dependencies in a configuration file and can library has already been loaded into the page before adding automatically download and include the code into the project. their own copy. On the other hand, web developers who intend Tools such as Auditjs [2] (for Node projects) scan dependencies to use third-party components such as advertising code for their for known vulnerabilities and can be integrated into automated website can attempt to limit potential damage by isolating these build processes; such solutions, however, work only if the components in separate frames whenever this is feasible. developer has an understanding of the risks associated with using vulnerable libraries, and is aware of the audit tool itself. Therefore, this functionality would ideally be integrated into the VI.RELATED WORK dependency management system of the programming platform Our work is related to prior studies on JavaScript security, so that a warning can be shown each time a developer includes measurements of vulnerability patching and dependency man- a known vulnerable component from the central repository. agement, a series of blog posts about inclusions of vulnerable Code Maintenance: Effective strategies to have web devel- libraries that inspired our more in-depth analysis, and existing opers update vulnerable libraries work only when vulnerability tools that implement a subset of our detection methodology. information is properly tracked and disseminated. Unfortunately, security does not appear to be a priority in the JavaScript library JavaScript Security: In [22], Nikiforakis et al. identify ecosystem. Popular vulnerability databases contain nearly no the network sources of JavaScript inclusions in the Alexa entries regarding JavaScript libraries. None of the 12 most Top 10 k websites, without special consideration for libraries popular libraries from Table I had a dedicated mailing list for or corresponding versioning semantics, and develop host-based security announcements. Furthermore, only a few JavaScript metrics for maintenance quality to assess whether remote code library developers provide a dedicated email address where providers could be compromised by attackers and subsequently users can submit vulnerability reports. When the release notes serve malicious JavaScript. Whereas Nikiforakis et al. study of libraries mention at all that a vulnerability has been fixed, where included code is hosted, we focus on the narrower but they often do not provide any details about the affected code, or semantically richer setting of libraries to investigate whether which prior versions are vulnerable. This is problematic because included code is outdated or known to be vulnerable, and we web developers using that library do not know whether the leverage our deep browser instrumentation to determine the vulnerable code is a function that they depend on, and whether initiators and causes of such inclusions. an update is required. Libraries can even silently reintroduce A separate class of related work examines specific at- vulnerabilities in order to remain backwards-compatible [12]. tack vectors in client-side JavaScript and conducts crawls Although jQuery is an immensely popular library, the fact to estimate how many websites are subject to the attack: that searching for “security” or “vulnerability” in the official Lekies and Johns [16] survey insecure usage of JavaScript’s learning centre returns “Apologies, but nothing matched your localStorage() function for code caching purposes, Son search criteria” is an excellent summary of the state of 1 and Shmatikov [31] examine vulnerabilities arising from JavaScript library security on the Internet, circa August 2016. unsafe uses of the postMessage() function, Lekies et A similar lack of adequate information about security issues al. [17] detect and validate DOM-based XSS vulnerabilities, has also been reported for the Android library ecosystem [3]. and Richards et al. [29] analyse websites’ usage patterns An additional complication is that patches are often supplied of the problematic eval() API. Yue and Wang [39] study only for the most recent versions of a library. Yet, these several insecure practices related to JavaScript, namely cross- versions are not necessarily backwards-compatible with the domain inclusion of scripts as well as the execution and versions still in use by many web developers. In fact, the short rendering of dynamically generated JavaScript and HTML lifecycles common in web development can become a burden through eval() and document.write(), respectively. Li for developers who need to keep up with frequent breaking API et al. [18] detect malicious redirection code hidden in JavaScript changes to maintain their websites free of vulnerable libraries. files on compromised hosts by deriving signatures from the differences between infected library files and the original, Third-Party Components: We observed that libraries in- benign copies. In contrast to the above work, we do not focus cluded by third-party components such as advertising, tracking on specific vulnerabilities, the use of security-critical functions, or malicious files. Instead, we provide empirical results at a 1Ember, the 50th most popular library in ALEXA (rank 52 in COM), is a notable exception with long-term support versions, a security mailing list, more abstract level to highlight and explain the prevalence of CVEs for vulnerabilities, and affected versions listed in security notices. benign-but-vulnerable JavaScript libraries in the wild.</p><p>13 Vulnerability and Dependency Management: Four stud- websites, uncovering issues such as duplicate library inclusions ies have examined vulnerability patching and dependency as well as transitive (and on average more vulnerable) inclusions management in large software ecosystems, although not with of libraries by third-party modules such as advertising, tracking, respect to JavaScript or the Web. Sonatype Inc., the company and social media widget code. behind Maven, released a report [32] examining security maintenance practices observed from the vantage point of Tools: From the point of view of our library detection the largest repository of Java components. According to the methodology, we are aware of two open source tools with a report, the mean time-to-repair of a security vulnerability in similar approach: Retire.js and the Library Detector extension. component dependencies is 390 days, 51,000 of the components Library Detector Chrome Extension. This browser exten- in the repository have known security concerns, and 6.2 % of sion [20] aims to detect the JavaScript libraries running on a downloaded components include known vulnerabilities. A key website. It injects a script into the website’s main document observation in the report is that fixing serious flaws in open to test for the presence of known libraries and extracts their source code does not stop vulnerable versions from being used. version, using dynamic detection code similar to the approach Our work in this paper shows that there are similar trends with presented in Section III-B. The extension does not warn against respect to JavaScript library usage on the Web. known vulnerabilities, does not reveal how or why a library Nappa et al. analyse the patch deployment process for was included, cannot reliably detect duplicate inclusions, and 1,593 vulnerabilities in 10 applications installed on 8.4 million does not analyse libraries loaded in frames. Windows hosts worldwide [21]. The authors show that the time Retire.js. Along with his blog posts, Oftedal released a tool [27] until a patch is released for different applications affected by to help web developers detect JavaScript libraries with known the same vulnerability in a shared library can differ by up to vulnerabilities. In a nutshell, Retire.js is a browser extension 118 days, with a median of 11 days. Furthermore, patching that intercepts network requests for JavaScript files while rates vary among applications and depend, among other factors, a website is loading and detects libraries based on known on the update mechanism. At most 14 % of vulnerable hosts file hashes, regular expressions over the file contents, and are patched before an exploit is released. API method signatures dynamically evaluated in an empty Thomas et al. propose an exponential decay model to sandbox environment. While we also use dynamic detection estimate patching delays of Android devices [35]. According and hash detection approaches in our methodology, Retire.js to the model, when a new version of the operating system is makes several simplifications that limit the tool’s utility for released, it takes 3.4 years to reach 95 % of the devices. our analysis. First, detecting a script as a library in an empty sandbox fails when the library has unmet dependencies. jQuery- Backes et al. build LIBSCOUT [3], a system to detect UI, for instance, requires jQuery and hence cannot be detected third-party library code in Android applications using a static dynamically if jQuery is not present in the environment. Second, approach based on abstracted package trees and method intercepting requests only at the network level may miss inline signatures. They find that 70.4 % of library inclusions in their scripts, dynamically evaluated scripts, and duplicate inclusions dataset include an outdated version, and it takes developers of cached scripts. Most importantly, Retire.js does not reveal an average of almost one year to migrate their applications to why a library was included, that is, whether the inclusion was a newer library version after the library has been updated. In caused by advertising code, for instance. We support all of a case study of two vulnerabilities, the authors show that the these scenarios and found interesting results as a consequence, average update delay is 59 and 188 days after the library patch is such as the vulnerability rates per inclusion type in Table V, first made available, while some applications remain without any and the duplicate inclusions observed in Section IV-G. update. Furthermore, 10 out of 39 advertising libraries contain one or more versions that improperly use cryptographic APIs. In contrast to LIBSCOUT, our detection approach requires that VII.CONCLUSION the library API methods used in our signatures not be renamed or removed. While a theoretical possibility, we believe that such Third-party JavaScript libraries such as Angular, Bootstrap eager minification settings are exceedingly rare on the Web and jQuery are are frequently used on websites today. While since they would necessitate processing all code potentially such libraries allow web developers to create highly interactive, referencing the library, including in HTML attributes and inline visually appealing websites, vulnerabilities in these libraries script. To the best of our knowledge, the default settings of might increase the attack surface of the websites that depend minifiers typically do not rename methods or remove dead on them. Hence, it is very important to ensure that only recent, code in client-side JavaScript (see, for instance, the Closure patched versions of these libraries are being utilised. Compiler [9]). This assumption allows us to detect the version In this paper, we presented the first comprehensive study on of a JavaScript library more reliably since most libraries self- the security implications surrounding JavaScript library usage version identify via their attribute or method. on real-world websites. We found that: Blog Posts: In 2014, a series of blog posts by Oftedal ([24], [25], [26]) raised awareness about the use of outdated JavaScript • 86.6 % of ALEXA Top 75 k websites and 65.4 % of libraries on the Web, and the fact that many large companies COM websites use at least one of the 72 JavaScript (including banks) use versions that are known to be vulnerable. libraries in our catalogue (Section IV-C); We complement this first exploration of the issue with a more • more than 37 % of websites use at least one library comprehensive detection methodology and a more detailed version with a known vulnerability, and vulnerable analysis. To the best of our knowledge, we are the first to report inclusions can account for a significant portion of all on the modality and causes of JavaScript library inclusions in observed inclusions of a library (Section IV-D);</p><p>14 • the median lag between the oldest library version used [12] M. Heiderich, “jQuery Migrate is a Sink, too?! or How jQuery Migrate on each website and the newest available version of un-fixes a nasty DOMXSS without telling us.” April 2013, http://blog. that library is 1,177 days in ALEXA and 1,476 days mindedsecurity.com/2013/04/jquery-migrate-is-sink-too.html. in COM (Section IV-F), and development of some [13] jQuery, “Write less, do more.” 2016, https://jquery.com/. [14] “#9521 (XSS with $(location.hash) and $(#<tag>) is needed?) – jQuery libraries still in active use ceased years ago; – Bug Tracker,” https://bugs.jquery.com/ticket/9521, June 2011. • surprisingly often, libraries are not referenced directly [15] “jQuery() | jQuery API Documentation,” https://api.jquery.com/jQuery/. in a page, but also inlined, or included transitively by [16] S. Lekies and M. Johns, “Lightweight Integrity Protection for Web other content such as advertising, tracking or social Storage-driven Content Caching,” in 6th Workshop on Web 2.0 Security media widget code (Table IV), and those inclusions and Privacy (W2SP 2012), 2012. have a higher rate of vulnerability than other, direct [17] S. Lekies, B. Stock, and M. Johns, “25 Million Flows Later – Large-scale inclusions (Table V, Section IV-E); Detection of DOM-based XSS,” in Proc. of CCS, 2013. • composition of content modules or third-party content [18] Z. Li, S. Alrwais, X. Wang, and E. Alowaisheq, “Hunting the Red Fox Online: Understanding and Detection of Mass Redirect-Script Injections,” in the same document can lead to duplicate inclusions in Proc. of IEEE Symposium on Security and Privacy, 2014. of a library and potentially nondeterministic behaviour [19] “McAfee SmartFilter,” https://www.trustedsource.org/en/feedback/url? with respect to vulnerability (Section IV-G); action=checklist. • remediation efforts are hindered by a lack of backwards- [20] J. Michel, “Library Detector for Chrome,” GitHub, April 2016, https: compatible patches (Section IV-H) and, more generally, //github.com/johnmichel/Library-Detector-for-Chrome. scant availability of information (Section V). [21] A. Nappa, R. Johnson, L. Bilge, J. Caballero, and T. Dumitras, “The Attack of the Clones: A Study of the Impact of Shared Code on The results of this work highlight the need for more Vulnerability Patching,” in Proc. of IEEE Symposium on Security and thorough and systematic approaches to JavaScript library Privacy, 2015. inclusion and dependency management on the Web. [22] N. Nikiforakis, L. Invernizzi, A. Kapravelos, S. Van Acker, W. Joosen, C. Kruegel, F. Piessens, and G. Vigna, “You Are What You Include: Large-scale Evaluation of Remote JavaScript Inclusions,” in Proc. of The causality trees shown in this work can be viewed online: CCS, 2012. https://seclab.ccs.neu.edu/static/projects/javascript-libraries/ [23] “<a href="/tags/Npm_(software)/" rel="tag">NPM</a>: The Node Package Manager,” https://www.npmjs.com/. [24] E. Oftedal, “Scanning Alexa Top 100,000 for JavaScript libraries with known vulerabilities,” February 2014, http://erlend.oftedal.no/blog/ ?blogid=142. ACKNOWLEDGEMENTS [25] E. Oftedal, “Scanning Fortune 500 for JavaScript libraries with known vulerabilities,” February 2014, http://erlend.oftedal.no/blog/?blogid=143. This work was supported by the National Science Founda- [26] E. Oftedal, “Scanning Norway for JavaScript libraries,” January 2014, tion under grants CNS-1409738 and CNS-1563320. http://erlend.oftedal.no/blog/?blogid=140. [27] E. Oftedal, “Retire.js,” GitHub, April 2016, https://github.com/RetireJS/ retire.js. REFERENCES [28] T. Preston-Werner, “Semantic Versioning 2.0.0,” http://semver.org/. [1] S. Arshad, A. Kharraz, and W. Robertson, “Include Me Out: In-Browser [29] G. Richards, C. Hammer, B. Burg, and J. Vitek, “The Eval That Men Detection of Malicious Third-Party Content Inclusions,” in Proc. of Intl. Do,” in Proc. of ECOOP, 2011. Conf. on Financial Cryptography, 2016. [30] P. Saxena, S. Hanna, P. Poosankam, and D. Song, “FLAX: System- [2] “Auditjs: Audits an NPM package.<a href="/tags/JSON/" rel="tag">json</a> file to identify known vulnera- atic Discovery of Client-side Validation Vulnerabilities in Rich Web bilities,” GitHub, https://github.com/OSSIndex/auditjs. Applications,” in Proc of NDSS, 2010. [3] M. Backes, S. Bugiel, and E. Derr, “Reliable Third-Party Library [31] S. Son and V. Shmatikov, “The Postman Always Rings Twice: Attacking Detection in Android and its Security Applications,” in Proc. of CCS, and Defending postMessage in HTML5 Websites,” in Proc of NDSS, 2016. 2013. [4] A. Barth, C. Jackson, and J. C. Mitchell, “Robust Defenses for Cross-Site [32] Sonatype, “The 2015 State of the Software Supply Chain Report: Hidden Request Forgery,” in Proc. of CCS, 2008. Speed Bumps on the Road to “Continuous”,” Sonatype.com, 2015. [5] M. A. Bashir, S. Arshad, W. Robertson, and C. Wilson, “Tracing [33] “SWFObject,” GitHub, https://github.com/swfobject/swfobject. Information Flows Between Ad Exchanges Using Retargeted Ads,” in [34] Y. Takamatsu, Y. Kosuga, and K. Kono, “Automated Detection of Session Proc. of USENIX Security Symposium, 2016. Fixation Vulnerabilities (Poster),” in Proc. of WWW, 2010. [6] “Bower: A package manager for the web,” https://bower.io/. [35] D. R. Thomas, A. R. Beresford, T. Coudray, T. Sutcliffe, and A. Taylor, [7] A. Cahn, S. Alfeld, P. Barford, and S. Muthukrishnan, “An Empirical “The Lifetime of Android API Vulnerabilities: Case Study on the Study of Web Cookies,” in Proc. of WWW, 2016. JavaScript-to-Java Interface,” Lecture Notes in Computer Science, vol. [8] “Chrome Debugging Protocol,” https://developer.chrome.com/devtools/ 9379, 2015. docs/debugger-protocol. [36] P. Vogt, F. Nentwich, N. Jovanovic, C. Kruegel, E. Kirda, and G. Vigna, [9] “Closure Compiler Compilation Levels,” April 2015, https://developers. “Cross-Site Scripting Prevention with Dynamic Data Tainting and Static google.com/closure/compiler/docs/compilation_levels. Analysis,” in Proc of NDSS, 2007. [10] P. Gill, V. Erramilli, A. Chaintreau, B. Krishnamurthy, K. Papagiannaki, [37] W3C, “Subresource Integrity,” https://www.w3.org/TR/SRI/, May 2016. and P. Rodriguez, “Follow the Money: Understanding Economics of [38] Wappalyzer, “Sites using JavaScript Frameworks,” https://wappalyzer. Online Aggregation and Advertising,” in Proc. of IMC, 2013. com/categories/javascript-frameworks. [11] “Google Hosted Libraries,” https://developers.google.com/speed/ [39] C. Yue and H. Wang, “A Measurement Study of Insecure JavaScript libraries/, July 2016. Practices on the Web,” in ACM Transactions on the Web, 2013.</p><p>15</p> </div> </div> </div> </div> </div> </div> </div> <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.1/jquery.min.js" integrity="sha512-aVKKRRi/Q/YV+4mjoKBsE4x3H+BkegoM/em46NNlCqNTmUYADjBbeNefNxYV7giUp0VxICtqdrbqU7iVaeZNXA==" crossorigin="anonymous" referrerpolicy="no-referrer"></script> <script src="/js/details118.16.js"></script> <script> var sc_project = 11552861; var sc_invisible = 1; var sc_security = "b956b151"; </script> <script src="https://www.statcounter.com/counter/counter.js" async></script> <noscript><div class="statcounter"><a title="Web Analytics" href="http://statcounter.com/" target="_blank"><img class="statcounter" src="//c.statcounter.com/11552861/0/b956b151/1/" alt="Web Analytics"></a></div></noscript> </body> </html>