Inter-process Communication Vulnerabilities In Firefox Extensions

(1)

Inter-process Communication

Vulnerabilities In Firefox Extensions

Dimitri Belfor

August 9, 2017, 31 pages

Supervisor: Jaap van Ginkel

Host organisation: Securify, https://securify.nl/

Host supervisor: Jurgen Kloosterman

Universiteit van Amsterdam

Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering

(2)

Abstract

Extensions allow users to modify the behavior of the internet browser they are using. Firefox’s new WebExtension framework is dependent on a message passing system to enable communication between web pages and highly privileged extensions. The communication between these processes could potentially be exploited to execute malicious code in a privileged context. Attacks exploiting the communication between processes are otherwise known as privilege escalation attacks.

The goal of this thesis is determining whether Firefox WebExtensions are vulnerable to privilege escalation attacks by means of messages between processes. To do this, the study describes a tool to detect privilege escalation attacks in Firefox WebExtensions by means of static analysis techniques.

This tool is able to detect known vulnerabilities and communication vulnerabilities in Firefox We-bExtensions. A case study on the Adblock for Firefox and Awesome Screenshot Capture Plus exten-sions is performed to show the correctness of the analysis tool. Which shows that WebExtenexten-sions may be vulnerable to privilege escalation vulnerabilities.

The study also concludes that most of the opt-out security policies used by Firefox are sufficient to protect developers from cross site scripting attacks by means of dynamic code evaluation in a privileged context.

(5)

Chapter 1

Introduction

Contemporary browsers have a lot of functionality built in when they are released. However, users are always looking for ways to improve their browsing experience. This is why most modern browsers also come with the option of adding extensions or plugins.

Many of these extensions are minor tweaks designed to enhance or customize the browsing ex-perience. Some extensions serve security-critical tasks and have access to core browser functionality which allows them to read and write user-sensitive data, or even access the file system of the operating system[6].

To enhance the browsing experience, many extensions can communicate with web pages[21]. Be-cause it cannot be assumed that all web pages are benevolent, extensions sometimes have to commu-nicate with malicious web pages. To make matters worse, developers may write faulty code which introduces vulnerabilities to the extension[2].

These vulnerabilities can then be exploited by attackers. The goal of an attacker is to gain access to the victim’s data or take over their machine. One way to accomplish this through extensions is by executing malicious code in the extension’s privileged context[2]. Many measures are taken to limit the damage a compromised extension can do. One of these measures is the principle of privilege separation. This principle is designed to ensure high privileged procedures are isolated from malicious and untrusted processes.

Extensions using the principle of privilege separation consist of two or more components with dif-ferent privileges[6]. In the case of Firefox WebExtensions there is a privileged background script and one or multiple content scripts. A background script can use the sensitive browser functionality and it runs in its own process which cannot be influenced by the web page. To communicate with web pages, the extensions use one or multiple content scripts. These scripts run with low privileges and hence they cannot access sensitive browser functionality.

To allow an extension to communicate with web pages, content scripts can be injected into the document object model (DOM) of any web page opened by the browser. The DOM is a logical tree representation of a (web) document and it serves as a connection between web pages and scripts or other programming languages[18]. To ensure web pages cannot gain access to procedures on the content script, content scripts and web pages are separated from each other by the same-origin policy (SOP).

The SOP restricts how a script from one origin can interact with a resource from another origin[25]. For example, a script from one web page cannot access resources from another web page unless it is given explicit permission to do so. The SOP also restricts which of the extension’s resources a web page has access to.

To enable the communication between web pages and content scripts, a message passing system was designed[21]. This message passing system is also used by browser processes to exchange infor-mation. For example, a content script can exchange information with the background script through the message manager.

(6)

To strengthen the security, most extensions are written with a single privileged module which offers a unified entry point to security sensitive procedures for all other components of the extension[6]. Recall that it is impossible for a web page to directly communicate with a background script unless given explicit permission to do so. This means an extension is secure until attackers get access to the privileged module.

Gaining access can be achieved by using the messages sent from a low privilege content script as a piggyback to send malicious code from a web page to the privileged processes[6]. Because Firefox’ message system does not check the contents of messages, it is up to the extension developers to make sure the messages are safe to be sent to privileged contexts[19].

This means the developers need a way to verify whether the privileged background scripts cannot be accessed and exploited by web pages through the message passing system.

1.1 Problem statement

Currently Firefox is doing manual inspection to ensure all extensions for their browser are benevolent and secure[2]. This process is time consuming and subject to human error. Because Firefox is switch-ing from a sswitch-ingle-process implementation to a multi-process implementation, the extension framework is also changing. This means the support for legacy extensions will be dropped by the end of 2017[29]. Because the support for legacy extensions is dropped, the extensions have to be ported or rewritten to work with the new WebExtension framework.

Great care has been taken to keep the security sensitive elements of extensions from getting at-tacked directly. However, extensions are not protected from privilege escalation attacks. Privilege escalation attacks target the badly programmed components of an extension to compromise the exten-sion with trusted messages from within[6]. Previous research has already found similar vulnerabilities in old versions of Firefox. For example, Barth, et al.[3] defined the cross-origin capability leaks in which pointers from one security origin are passed to another security origin allowing it to change the prototype property (i.e. adding additional functions) of an honest JavaScript object. These added functions could then be exploited by an attacker to gain access to privileged parts of the browser.

Previous research has defined security vulnerabilities like privilege escalation vulnerabilities as in-formation flow problems where the data from an insecure source flows to a security sensitive data sink[2]. A potential way to solve these information flow problems could be by using a static analysis on a derivative of the abstract syntax tree (AST). The AST is a tree representation of the structure of the source code of a program. By traversing this tree, vulnerable statements can be detected, and their behavior can be followed through the tree.

In this paper, we present a tool aimed at detecting privilege escalation vulnerabilities of Firefox WebExtensions using context-insensitive, path-insensitive and flow-sensitive static analysis of the AST.

1.2 Previous research

Previous research regarding the privilege escalation of JavaScript based WebExtensions has only targeted Google’s Chrome browser[6]. While extensions for Firefox and Chrome browsers are written in JavaScript, the API calls for each browser are different. Thus, it is still necessary to verify whether the results of previous research hold up for Firefox’s new WebExtension framework.

Some research only took paths from sources to sinks into account, ignoring the message passing interface[9,13,26,2,4]. Other approaches only took a safe subset of the language into account which required additional computing time and also ignored dynamic features like eval[8,7,12]. Yet other research was done on creating a full framework for static analysis which only focused on an older version of JavaScript[13,30,27].

Because dynamic analyses have significant run-time overhead and static analyses typically require source code annotations[14], this paper will present a static analysis tool that requires no source code annotations. Having an analysis tool that reports privilege escalations within an extension will aid developers in migrating to the new WebExtension framework. Because it is beyond the state of the

(7)

art for different types of security analysis tools to automatically detect and report vulnerabilities with high accuracy without human interference[2], the tool presented in this thesis will focus on efficiency and speed rather than minimizing the amount of false positives.

1.2.1 Research questions

Previous research already proved the existence of privilege escalation vulnerabilities for Google’s Chrome browser[6]. The goal of this research is finding similar vulnerabilities in Firefox’ new WebEx-tension framework, which leads to the following research question:

RQ. Are Firefox WebExtensions vulnerable to privilege escalation attacks by means of messages between processes?

For the sake of a more in depth research, we will mainly focus on the security of inter-process communication because this is a novel concept of WebExtensions[21]. To determine the security of the WebExtension framework, it is first necessary to determine how it works exactly. This leads to the first sub-question:

(i) How can the communication functions in the WebExtension application programming interface (API) be exploited for privilege escalation attacks?

To show the relevance of the findings of the literature study, a proof of concept analysis tool will be built that can detect privilege escalation vulnerabilities. To detect vulnerabilities in the source code without running an extension, a static analysis tool will be implemented. This led to the last two sub-questions:

(ii) Can the AST be used to detect sources, sinks and inter-process communication statements in WebExtensions?

(iii) Can data paths from vulnerabilities to known sinks and inter-process messages be detected by analyzing the AST?

1.3 Research method

To answer the first sub-question, a literature study is conducted on Firefox’ WebExtension API and its documentation. This literature study will determine what communication functions are available in the WebExtension API. In addition to reading the WebExtension documentation, a literature study on vulnerability detection in JavaScript will be conducted.

The information from these literature studies will be combined to design and implement a proof of concept vulnerability analysis tool.

This tool will analyze the source code of WebExtensions and detect vulnerable statements. These vulnerable statements are used to detect data flows to different processes. To identify known vul-nerabilities an AST will be used. To acquire the AST, the source code of all JavaScript files in an extension will be transformed to an intermediate representation which is known as the AST. This AST will contain information of the scope of each statement and the order in which the statements are performed. These statements in the scope sensitive AST will then be used to detect the sources and sinks in a program.

The detected sources and sinks will be used in a points-to-analysis to determine the aliases of the vulnerable statements. The set of sources, sinks and aliases will then be traced through the program to find their other usages, like call sites. All sources and their aliases are traced to determine whether they are sent to another process in a message, which may identify a privilege escalation. The origin of each sink is checked as well. If the sink originated from a message it is potentially insecure and can be exploited in a privilege escalation attack.

1.4 Organization

This paper is organized as follows, Chapter 2 describes the results of our literature study on Firefox extensions and the communication vulnerabilities. This is followed by an explanation of static analysis

(8)

in Chapter 3. In Chapter 4, our implementation for detecting potential privilege leaks is presented, and the results of our research will be demonstrated with a case study in Chapter 5. These results will be analyzed and discussed in Chapter 6 along with recommendations for further research.

(9)

Chapter 2

Firefox’ WebExtension Framework

This chapter will explain the key concepts of inter-process communication implemented in the Firefox browser. In addition to explaining the communication between processes, the content security policy will also be explained. The remainder of the chapter will demonstrate the impact of privilege escalation vulnerabilities by giving an example of a vulnerability and an exploit.

2.1 Multi-process Firefox

Older generations of the Firefox browser ran within a single process. To compete with contemporary browsers, Firefox is switching to a multi-process variant[15]. This choice was made to improve the performance, stability and security of the browser.

In multi-process Firefox, the browser UI is run in a separate process from the web content. Each web-related content process communicates with the global parent (i.e. the browser) by means of the inter-process communication (IPC) protocol which is defined in the inter-protocol definition language (IPDL)[16].

2.2 Message passing

The IPDL is written in C++, and is only meant to be used for developing Firefox’ Gecko web engine. Firefox exports a message manager API in JavaScript which can be used by extension developers to communicate between the different processes of the browser. This message passing works in an hierarchical way in which processes can only communicate directly with their parents or children[21]. The message manager API only ensures the communication between the processes happens in an orderly fashion. This means single messages cannot cause the whole parent process to block while waiting for replies from the child processes because this may cause the whole browser to be unresponsive.

The message manager doesn’t check the contents of messages for vulnerable or malicious content. This means it is up to the extension developer to make sure the messages sent between processes are harmless or not tampered with.

2.2.1 Message managers

Each process boundary has its own message manager, as can be seen in Figure2.1. Each instance of the browser has one global parent process message manager (GPPMM) which can communicate with one multiple parent process message managers(PPMM). The GPPMM can either send a message directly to one of the PPMMs or it can broadcast a message to all its children (i.e. PPMMs) by sending a message to the parent in process message manager (PIPMM) which sends it to the child in process message manager (CIPMM).

The parent process has one PPMM per child process and the child will only listen to that specific PPMM. Each child also only has one child process message manager (CPMM) which is connected to

(10)

the PPMM.

Figure 2.1: Process Managers and Process Boundaries[21].

2.3 WebExtensions

Like the browser, WebExtensions also consist of multiple processes, namely a long running background process and one or multiple content scripts. The manifest.json file is the only mandatory file in an extension and the other files are all optional. This manifest contains pointers to other files, along with an optional description of the content security policy (CSP) of the WebExtension, see Figure2.2.

Figure 2.2: The anatomy of a WebExtension[17].

The manifest also specifies what content scripts will be injected in which web pages. The manifest in Listing 2.1 specifies that the content.js script should be injected in all domains matching the

(11)

regex https://*.trusted.org/*.

1 //manifest.json

2

3 "content_scripts": [ 4 {

5 "matches": ["https ://∗. trusted .org/∗" ], 6 "js": [ "content. js "]

7 } 8 ]

Listing 2.1: A manifest specifying the content.js script should be injected in all domains matching trusted.org.

2.3.1 Content security policy

The CSP declares which of the extension’s resources are available to external processes[11]. The CSP serves as an added layer of security and as enforcement of the SOP. The CSP makes it harder for an attacker to inject data or scripts into the extension (or web page). The primary goal of the CSP is to prevent three types of vulnerabilities[31]:

• Cross-site scripting (XSS): the ability to inject and execute untrusted scripts in a vulnerable application.

• Clickjacking: forcing users to take unwanted actions in a compromised application by overlaying content with attacker-controlled content.

• Mixed content: Accidentally loading resources from insecure protocols on pages with a secure (HTTPS) protocol.

By default, the WebExtension CSP only allows access to script and object resources local to the extension. Apart from that, evaluating strings as JavaScript and executing inline JavaScript is not allowed. These rules on their own help mitigate XSS risks by declaring what dynamic resources can be used by an extension script or a web page[11]. However, developers still have to manually escape or encode the messages sent between processes to ensure full security[6].

It is still possible to use eval and other dynamic code execution mechanisms. But the developer has to explicitly declare their intent to use these resources in the CSP. These measures should be sufficient to control the origin of resources used within a web page or extension. However, multiple studies have found that these policies are often ignored, or too many privileges are requested in the CSP[1,31].

It is also possible to bypass the rules enforced by the CSP, see Listing2.2. One of the underlying assumptions of the CSP is that domains whitelisted in the policy serve secure content. If one of the whitelisted domains is compromised, an attacker can use that domain as a disguise to serve or even execute their malicious scripts in a protected application. Which might indicate that an otherwise secure application can still be exploited by attacking it through a compromised whitelisted domain.

1 Content−Security−Policy: script−src example.org

2 partially −trusted.org/foo/bar.js

3 // Allows loading of untrusted resources via : 4 <script src="//example.org?

5 redirect =partially−trusted.org/ evil / script . js ">

Listing 2.2: Bypassing CSP path restrictions[31].

In addition to the current flaws of the CSP, it cannot be assumed it is properly implemented. Twelve out of fifteen top domains introduce full CSP bypasses[31]. Around 87% of the more than 600,000

(12)

web pages analyzed by Weichselbaum, et al. allow arbitrary string to be executed as JavaScript and around 82% of the web pages allow inline JavaScript to be executed[31]. In addition to having a lenient CSP, most Firefox extensions run with too many privileges[4].

The CSP has a lot of potential for protecting developers but a lot of the rules can be circumvented by exploiting a poorly designed CSP of the attack target or one of its whitelisted domains.

2.4 Vulnerabilities

Although Firefox is well protected at first glance, developers are given a lot of freedom in building their extensions. This freedom may enable the developers to make mistakes. Recall that every process is running isolated from other processes and the only way to interact is through the message manager. If the messages sent between processes aren’t sanitized or otherwise checked for malicious intent the extension might be vulnerable to privilege escalation attacks.

One way for an attacker to get his malicious code to run in a privileged context is by exploiting the communication between the processes to launch an attack by sending his untrusted code to the privileged processes. For example, gaining access can be achieved by supplying the content script with a string of JavaScript code which can be sent to higher privileged components where it can be executed with the full privileges of the application.

None of the messages are sanitized by the API by default, so it is up to the extension developer to ensure the messages are safe to be sent. The source code of all extensions can be downloaded from Firefox’ Add-on web page[20], which makes it possible for an attacker to analyze any of the extensions for privilege escalation vulnerabilities and target the users of that specific extension.

In the case the attacker is targeting a specific extension by exploiting the privilege escalation, it isn’t necessary to directly attack the highly privileged background script. The only requisite is one or multiple poorly programmed content scripts[6].

2.5 A motivating example

In the worst-case scenario, a privilege escalation attack can allow the attacker to execute code in a privileged context by tricking an unprivileged content script to send the code embedded on his web page to a background script, see Figure2.3.

Figure 2.3: A way to attack an extension using messages.

To demonstrate this worst-case scenario, consider a lenient CSP which allows both the evaluation of inline JavaScript and the execution of strings as JavaScript code leaving the extension open to XSS attacks. In addition to being open to XSS attacks, the extension also inserts its content script into all visited web pages, see Listing 2.3. While the likelihood of this CSP actually being used in the field is small, recall that Weichselbaum, et al. showed that usage of unsafe-inline and unsafe-eval was prevalent[31].

(13)

1 //manifest.json 2 "content_scripts": [ 3 { 4 "matches": ["http://∗", "https ://∗"], 5 "js ": ["content. js "] 6 } 7 ] 8

9 "content_security_policy": default−src ∗; style −src ∗ ’unsafe−inline ’; 10 script −src ∗ ’unsafe−inline’ ’unsafe−eval’;

Listing 2.3: A CSP allowing inline JavaScript, strings executed as JavaScript and scripts from all origins.

The extension is composed of two components: an unprivileged content script, and a privileged background script. The background script has access to all of the privileged API. This API allows the extension to read and write the saved user credentials or read and write the stored cookies for example. When the user visits a web page, the extension’s content script is injected into the DOM allowing the background script to indirectly communicate with the page by using the content script as a proxy. Messages sent from the web page to the background script are passed through the content script by using tags which is a popular way of sending messages in JavaScript[6].

A poorly programmed content script which does no sanitizing of the messages passed through can be seen in Listing 2.4. The corresponding background script of the extension can be seen in Listing

2.5.

1 //content. js

2 /∗ Adds a listener to the global message manager.∗/

3 window.addEventListener("message", function(event) { 4 switch(event.tag) {

5 case ’to−background’:

6 sendToBackground(event.message); 7 /∗ Optional other cases can be added∗/ 8 } 9 }); 10 11 function sendToBackground(message){ 12 browser.runtime.sendMessage({ 13 tag: ’ evaluate ’ , 14 source: ’ contentscript ’ , 15 message: message 16 }); 17 }

Listing 2.4: A vulnerable content script which can be abused by malicious pages.

The source code of all extensions in the Firefox add-on store can be downloaded and inspected. This allows an attacker to scan the store for extensions with vulnerable communications and build a web page that targets the users of the extension. For example, the attacker could build a page that sends a message to the extension’s content script when the user clicks a button on the page, see Listing

2.6. As can be seen, the attacker uses the tag defined in the content script to send his malicious script to the background script where it is then executed with all the privileges of the background script.

This allows the malicious page to carry out XSS attacks and depending on the privileges of the back-ground script. One way to avoid this exploit is by disallowing the execution of strings as JavaScript. However, sometimes developers are forced to use this type of programming when they are porting a legacy extension on a tight schedule. Another option to avoid the exploit can be to only execute the

(14)

1 //background.js 2

3 /∗ Registers a message listener in the background script∗/

4 browser.runtime.onMessage.addListener(function(message) { 5 switch(message.tag) {

6 case ’evaluate ’ :

7 if (message.source === ’contentscript’) { 8 /∗ Execute the message it recieves ∗/ 9 eval(message.message);

10 }

11 } 12 });

Listing 2.5: A vulnerable content script which can be exploited by malicious pages.

1 //attacker_page.js 2

3 /∗ Retrieves a pointer of the button element from the DOM∗/

4 var malicousButton = document.getElementById("page−script−button"); 5

6 /∗Registers an on click event on the button∗/

7 maliciousButton.addEventListener("click", sendMaliciousMessage); 8

9 function messageContentScript() { 10 window.postMessage({

11 tag: ’ to−background’,

12 /∗ this message can now be used to send malicious scripts to the content script ∗/ 13 message: ’~malicious script~’

14 });

15 }

Listing 2.6: A malicious web page exploiting the content script’s tag message.

string if it originated from the content script, which can be achieved by adding additional information to the message object when sending it to the background script.

This example shows that it is necessary to have a tool that can analyze the source code and deter-mine whether an extension breaks down the isolation designed by Firefox. This will help extension developers recognize vulnerable areas in their extensions and secure these parts.

(15)

Chapter 3

Source code analysis

There are multiple ways to analyze the source code of WebExtensions in order to detect potential vulnerabilities. This chapter will first explain why static analysis was chosen for the implementation of the vulnerability analysis. The remainder of the chapter will explain the choices made when implementing the static analysis and their effect on the accuracy of the analysis.

3.1 Comparison between static and dynamic analysis

There are three types of source code analysis namely static analysis, dynamic analysis and a com-bination of both types called blended analysis. Static analysis usually requires less user interference but dynamic analysis is reported as being more precise[9].

In the static variant, the analysis is performed without executing the program. In some cases, manual checks have to be done on the results to acquire the true positives. Static analysis operates by building a model of the state of the program, which in this tool would be an AST with scope information to model the flow of information through all vulnerable statements.

Dynamic analysis in contrast to static analysis, is done by executing the program. This method usually requires source code annotations or test input by the developer because it is unknown up front what paths in the program are going to be executed and what the initial input is going to be. Because JavaScript is a dynamic language[23], dynamic analysis will be able to give more precise information of the program state in a given run[9]. This means a dynamic analysis will have a higher accuracy because the amount of false positives is lower. The amount of true positives might be lower for a dynamic analysis depending on what program paths are analyzed. Because it is time consuming to take all possible program paths into consideration.

Both static and dynamic analysis can be combined in a blended analysis, which offers the best of both worlds[30]. Because static and dynamic analyses both find different results, running both analyses side by side would give the most extensive results at the cost of additional computing time.

3.1.1 Static Analysis

Comparing the two forms of analysis, static analysis seemed to be the most appropriate option be-cause the first priority is determining whether vulnerable communication exists. Determining whether communication is vulnerable doesn’t require a consideration of full possible program paths but rather a detection of specific statements in the source code.

One of the most compelling reasons for using a dynamic analysis is that it can be used to determine the flow of the program when taking the dynamic features of JavaScript into consideration. One example of a dynamic feature is the dynamic code evaluation for example by means of the eval statement[9]. In the current analysis, an extension is considered compromised if it is able to execute dynamic code. This means it is unnecessary to take further program behavior into consideration if

(16)

dynamic code execution statements have been detected. If it is possible to find a data flow from a communication channel to one of these statements, extension is considered compromised.

3.2 The abstract syntax tree

Because the source code of the extension is going to be analyzed, we needed a way to represent the flow of statements. To do this, the Abstract Syntax Tree (AST) is used. The AST is a tree like representation of the source code of a program where each node represents a statement within the language, see Figure3.1.

Figure 3.1: The AST for the following code: 3 * 2 + 4.

Depending on the traversal of the tree, the order of execution of the statements in the tree is kept intact. This tree structure also makes it easier to transform the source code into a useful structure for further analysis. For example, the AST can be rewritten into a control flow graph which in turn can be used to find all traversable paths within a program.

3.2.1 Points-to analysis

A points-to-analysis attempts to determine the set of objects or variables to which a reference or ob-ject is pointing[12]. A points-to-analysis is usually the best way to determine the flow of information within a program because it results in the call sites of a function and the aliases of variables. Most points-to-analyses work by determining the heap references and addresses[27]. However, because of the dynamic nature of JavaScript, it is hard to identify precise call targets, which might have a neg-ative effect on the accuracy of the tool. The points-to-analysis used in this analysis will only be used to detect the flow of information between variables and functions, ignoring the more complex object references.

To demonstrate the points-to-analysis, consider the snippet in Listing3.7. This snippet shows the variable original being passed as the parameter to the function returnAliased. returnAliased assigns its parameter to aliasInFunction which is then returned. Because the return value of returnAliased is assigned to alias, we can assume the value of original is assigned to alias. The resulting points-to graph is shown in Figure3.2. Each edge in this graph represents an assignment or or a reference to the next node.

3.2.2 Context sensitivity

Context sensitive analysis considers the calling context of a statement when analyzing the target of a function call. Having a context sensitive analysis is generally a good way to reduce the amount of false positives the analysis finds at the cost of more computing power. However, extensions show very little variance on the context sensitivity [13]. Because the precision variance is low, a context insensitive approach should be sufficient for this analysis.

(17)

1 function returnAliased (value) { 2 let aliasInFunction = value; 3 return aliasInFunction; 4 }

5

6 let original = 5;

7 let alias = returnAliased(original );

Listing 3.7: A snippet showing the data flow from original to alias.

Figure 3.2: The points-to graph of the snippet in Listing3.7

It is hard to guess the arguments of a function through static analysis because JavaScript is a dynamic language. One of the dynamic features of JavaScript is having variadic functions which accept a variable number of arguments. This feature makes it hard to statically derive the context in which a function is called[23]. This tool will analyze functions on either using unsanitized variables or on returning a known source. The different types of arguments are only taken into consideration if they are not dynamic and can be determined from within the visible scopes.

3.2.3 Path sensitivity

A path sensitive analysis takes the different branches of control flow statements into account. The only added value of a path sensitive analysis in this case would be that it allows the program to estimate the likelihood of reaching a certain statement within the program.

Because the goal is to detect whether specific statements are used in the program, and not to estimate the likelihood of reaching each statement, implementing a path insensitive analysis is suffi-cient. A path insensitive analysis does not differentiate between the different branches of control flow statements and analyzes the code as if both branches happened.

3.2.4 Flow sensitivity

Lastly, a flow sensitive analysis takes the order of statements in a program into account. Because this analysis uses the AST as a basis, it is inherently flow sensitive. Because of JavaScript’s dynamic nature, flow-insensitive analyses have low precision[13], and thus should not be used when doing an information flow analysis.

(18)

Chapter 4

Security Analysis Method

Because the tool will use static analysis to determine whether an application is vulnerable, the source code first has to be transformed into a static representation of the program. The source code trans-formation and analysis are described in this chapter. The full implementation of the analysis tool can be found on the author’s GitHub page[5].

4.1 Parsing

The analysis tool uses esprima[10] to transform the source code into the AST. Esprima is a tool to perform lexical and syntactical analysis of JavaScript programs. Esprima itself is also written in JavaScript and the source code is open source which makes extending the tool possible. Scope information is also necessary to determine the aliases of variables and call sites of functions. That is why this information will also be added to the AST.

4.2 Scoping

Getting the scope information is done by using the escope[28] tool which is included in the esmangle project. This tool adds scope depth annotations to the AST. However, the escope tool only con-siders the global and function scopes, disregarding the statements within control sequences such as for-loops and if-else statements.

Because the analysis is path-insensitive, it is sufficient to hoist the statements from a control se-quence and analyze them in the parent scope, as can be seen in Listings4.1and4.2. This also allows the analysis to check both clauses of an if statement without considering whether they can get reached. Because this does not change the order of the operations, the analysis is still flow sensitive. As can be seen, hoisting only works on the body of the loop. The analysis does not care whether the variable i is defined or not because vulnerable operations usually happen within the loop body and not in the declaration.

1 let iteration_number;

2 for ( let i = 0; i < 10; i++) { 3 iteration_number = i;

4 console . log(iteration_number); 5 }

Listing 4.1: A snippet with statements nested in the control block

1 let iteration_number; 2 iteration_number = i;

3 console . log(iteration_number);

Listing 4.2: The same snippet after hoisting the statements

(19)

4.3 Sources and sinks

Di Paola, et al.[22] published a list of known DOM based XSS vulnerabilities in a wiki page. How-ever, a set of communication vulnerabilities also has to be considered. This section describes what vulnerabilities can be detected by the analysis tool. Vulnerabilities are split into two groups: sources and sinks.

4.3.1 Sources

A source is any type of input to the program which can be generated by the user. This input is unsafe or untrusted if it is not checked for any malicious intent. Because we cannot assume the CSP will provide sufficient protection against attacks, we will also include the list of DOM based XSS sources reported by Di Paloa, et al.[22]. The DOM based sources considered in this analysis can be found in Table4.1.

Because this research is considering communication paths to and from modules in the extension as vulnerable as well, the functions supplied by the API to communicate between process are also considered as sources. This leaves us with the sources described in Table4.2.

An example of a source which is marked as on assignment and a communication source can be seen in Listings4.8and4.9respectively.

1 //password_save.js 2

3 /∗ Gets the DOM element of the password field∗/

4 var passwordField = document.getElementById("pwdField"); 5 /∗ Assigns the value of the password field to the variable source∗/ 6 var source = passwordField.value;

Listing 4.8: An unsanitized source originating from the DOM.

1 //receive_data.js 2

3 /∗ Registers a printing the message data to the console .∗/ 4 window.addMessageListener(’message’, function (message) { 5 console . log(message.data);

6 }

Listing 4.9: An unsanitized source originating from a message.

Table 4.1: Reported DOM sources.

Sources Comment document.URI On assignment document.documentURI On assignment document.baseURI On assignment document.cookie On assignment location On assignment location.href On assignment location.search On assignment name On assignment data On assignment value On assignment window.name On assignment

(20)

Table 4.2: Reported communication sources.

Sources Comment

addMessageListener Second argument, invoked on any message manager addListener Second argument, invoked on any message manager addEventListener Second argument, invoked on any message manager addWeakMessageListener Second argument, invoked on any message manager

4.3.2 Sinks

Extensions are primarily written in JavaScript and HTML, and JavaScript provides several methods for converting strings to code, such as eval and setTimeout. If used improperly, these methods can introduce code injection vulnerabilities that compromise the extension.

In his study on the usage of the eval function, Richard, et al. showed that it was widely used on web pages[24]. A more recent study by Weichselbaum, et al.[31] also showed that the unsafe-inline and unsafe-eval flags were still used in the CSPs of 87% and 82% of the tested websites respectively. Because eval and other dynamic code execution functions are still in use, it may be relevant take them into consideration as potential sinks. Even if the CSP should restrict the usage of the statement. Apart from the known sinks, we also have to consider communication functions which send messages to another process. All sinks considered in this analysis can be seen in Tables4.3and4.4.

Table 4.3: Reported DOM and dynamic code evaluation sinks. DOM and dynamic evaluation Sources Comment

eval First argument

function First argument

setTimeout First argument

setInterval First argument

document.write On assignment

document.writeln On assignment

Table 4.4: Reported communication sinks. Communication Sources Comment

postMessage Second argument, invoked on any message manager sendAsyncMessage Second argument, invoked on any message manager sendSyncMessage Second argument, invoked on any message manager broadcastAsyncMessage Second argument, invoked on any message manager sendAsyncMessage Second argument, invoked on any message manager

4.3.3 Detection

The detection of vulnerable statements happens in two phases. The first phase is detecting the sources and the second phase is detecting the sinks.

Detection of the sources is done by first checking variable declarations, assignments, member ac-cesses and function declarations.

First, all variable declarations are checked on whether a source is assigned to them. If this is the case, the variable is marked as a potential vulnerability leak. The same is done for all variables which have a known source assigned to them after they have been declared. To check for the communication sources, we have to find the message managers and their aliases and check whether any of the communication functions described in Table4.1are invoked on this message manager.

(21)

Finally, function declarations are checked on whether they return a source, or if they try to manip-ulate a known source. All variables and functions found this way are also kept track of because they could also be exploited to gain access to the process.

The second phase consists of detecting the sinks in the extension. Detecting the sinks is done in a similar way as detecting sources but in this case, the variable declarations and assignments are ignored because it is only necessary to check function calls and member accesses, see Table4.3.

All detected sources and sinks are saved. In addition to saving the sources and sinks, their location in the source code is also saved to provide clear feedback of the vulnerabilities and their context.

4.4 Data flow

After the sources and sinks have been detected, it is necessary to trace their behavior through the whole extension. This has been done by using a simplified variant of a points-to-analysis. This works by first detecting all aliases of the sources and then verifying if there is no way for a source to be used by a sink.

4.4.1 Variables

For each detected source variable, all variable assignments and declarations in the visible scopes are evaluated. A variable is considered an alias if one of the previously known sources is assigned to the evaluated variable. The alias is then saved as a source and the same evaluation is repeated for this alias until all variable statements in the scope have been exhausted.

4.4.2 Functions

A function is considered to be a source if it returns one of the sources described in Table 4.1, either explicit or aliased.

If one of the variable sources is passed as a function parameter, the function is analyzed again. Only now, the analysis checks whether the parameter is aliased and if either one of the parameter or the alias is returned.

A function is considered a sink if it executes the source or sends it to another process, see Table

4.3.

4.5 Output

The tool also checks the manifest of the extension to determine the contents of the CSP. By reporting the CSP, it is possible to determine the severity of the vulnerabilities.

The contents of the CSP are followed by a report of the detected vulnerabilities and their context in the source code and whether it was a source or a sink. This is followed by a report of the sinks that can be reached by the detected sources.

The vulnerable statements are also reported because the static analysis is not able to detect all paths in the extension because of the dynamic features of JavaScript. By reporting the vulnerable statements, it is still possible for the developer to determine whether a statement is secure or not.

4.6 Gathering test data

To verify whether the analysis tool was able to find examples of vulnerable extensions, a Python script was written to download the top 376 Firefox extensions[20]. After downloading all extensions, the We-bExtensions were filtered out since legacy extensions do not make use of inter-process communication APIs and therefore they are useless as test data.

Because WebExtensions are a new paradigm in developing Firefox extensions, the actual set of data to test the effectiveness of the analysis is limited. After filtering the WebExtensions from the

(22)

downloaded extensions, we were left with a small amount of testable extensions. From the 376 downloaded extensions, only 57 (15.16%) were WebExtensions. From these extensions, two examples were selected to demonstrate the functionality of the analysis.

(23)

Chapter 5

Results

Before the case studies were performed, the CSPs of all WebExtensions were first checked on what operations were allowed within the extensions. Out of all the WebExtensions, only 8 (14.04%) had custom CSPs. And from the extensions with custom CSPs, only one extension allowed for the usage of eval and inline JavaScript. The first case study will focus on the extension that allows the execution of dynamic code because it may be vulnerable to privilege escalation attacks.

The second case study is included to demonstrate that the analysis tool is also able to detect communication vulnerabilities if it is impossible to execute dynamic code.

5.1 Case study of the Adblock for Firefox extension

The only extension allowing the usage of eval and inline JavaScript is Adblock for Firefox. This extension blocks all advertisements on visited web pages. Adblock for Firefox is chosen to demonstrate the analysis because dynamic code execution can introduce vulnerabilities.

First of all, looking at the CSP, the first thing we notice is that the following scripts are inserted into all web pages: port.js, functions.js, filtering/filteroptions.js, adblock_start_common.js and adblock_start_firefox.js, see Listing5.10.

1 //manifest.json 2 { 3 "matches": ["http://∗/∗", "https://∗/∗"], 4 "js": [ 5 "port. js ", 6 "functions. js ", 7 " filtering / filteroptions . js ", 8 "adblock_start_common.js", 9 "adblock_start_firefox . js " 10 ], 11 "run_at": "document_start", 12 "all_frames": true 13 }

Listing 5.10: A part of the manifest of the Adblock for Firefox extension.

When running the analysis, the first focus was on detecting the sinks. Because the extension allows for the evaluation of dynamic code, the priority was detecting eval or similar statements in the background script.

While there were no eval statements found in any of the background scripts, the functions.js content script has a background call function, see Listing5.11. As can be seen on lines 5 and 6, this function can be called with any amount of arguments. Because of this dynamic functionality it is difficult to predict the behavior of the function at runtime. However, it is safe to assume that the

(24)

content script sends a message to one of the background scripts with a string of JavaScript code or a function object. This string or function object will then be executed by the listener function on the background script. This will allow the dynamic executed function to operate with the same privileges of the background script. The function in Listing5.11by itself is not dangerous, as long as there is no way for a web page to access it.

1 //functions. js 2

3 var BGcall = function () { 4 var args = [];

5 for (var i = 0; i < arguments.length; i++) 6 args .push(arguments[i]);

7 var fn = args. shift ();

8 var has_callback = (typeof args[args.length − 1] == ’function’); 9 var callback = (has_callback ? args.pop() : function () { 10 }); 11 12 if (! has_callback) { 13 callback = null; 14 } 15

16 browser.runtime.sendMessage({ command: ’call’, fn: fn, args : args }, callback ); 17 };

Listing 5.11: A part of functions.js content script of the adblock for Firefox extension. To verify whether this vulnerable function is secure, the other files are searched for a listener function that uses the command tag defined on line 16 in Listing5.11.

This leads to a message listener in the background.js script which can be seen in Listing5.12. This function is encapsulated in parentheses and does not have an identifier. By encapsulating a function in parentheses, the developers have created a private member function. This function is hidden from outer scopes and can’t be called explicitly. The function is run only once to register the listener which responds to the call tag. To increase security of the listener, a check is done on lines 8 and 9 of the script. If the function is defined in the background script, it can be executed. Otherwise the listener does nothing. This makes sure the background script cannot be tricked into running a malicious script via this function by a compromised content script.

However, on line 16 of the content script, see Listing 5.11, a list of arguments is added to the message object. In addition to the arguments, a callback function is also added to the message. This callback function can be any function object added to the arguments of the BGcall function. Three of the functions on the background script accept a callback function and actually execute it. Recall that the BGcall dispatch function can execute functions if they are defined in the background script. This could mean an attacker can execute any script they supply as argument when calling any of the vulnerable three functions on the background script. This callback function is then supplied as an argument for yet another function as can be seen from the get_exclude_filters_text function in Listing5.13.

The callback could potentially be used to execute a malicious script. However, the danger depends on being able to get access to the BGcall function in the functions.js content script.

We cannot delve deeper into the further execution of the chrome.storage.local.get() API call without executing the code. But it may be possible for an attacker to exploit this extension’s callback system to execute their own code in a privileged context. However, it is also possible for an attacker to take control of an extension without executing their own code. The second case study will demonstrate the detection of vulnerabilities in an extension with a CSP that doesn’t allow the use of eval or similar statements.

(25)

1 //background.js 2

3 (function () {

4 browser.runtime.onMessage.addListener( 5 function (request, sender, sendResponse) { 6 if (request . command != ’call’)

7 return; // not for us 8 var fn = window[request.fn]; 9 if (typeof fn !== ’function’) {

10 log( ’ fn ’ , fn , ’not found on background page, request: ’ , request );

11 return; 12 }

13 request . args . push(sender);

14 var result = fn.apply(window, request.args, sender); 15 sendResponse(result);

16 } 17 ); 18 })();

Listing 5.12: A function in the background.js script of the Adblock for Firefox extension which can execute dynamic code.

1 //background.js 2

3 var get_exclude_filters_text = function (callback) { 4 if (typeof callback !== ’function’) {

5 return; 6 }

7

8 chrome.storage.local . get( ’ exclude_filters ’ , function (response) 9 {

10 callback(response[ ’ exclude_filters ’ ]); 11 });

12 };

Listing 5.13: A function on the background script which uses a callback function.

5.2 Case study of the Awesome Screenshot Plus extension

The Awesome Screenshot Plus extension allows users to take a screenshot of their browser. This screenshot will be hosted on the developer’s own server and it can be downloaded by the user.

The manifest of this extension restricts the execution of dynamic code implicitly because no CSP is defined. This causes Firefox to append the default CSP which can be seen in Listing5.14. Because it isn’t possible to execute dynamic code, an attacker can’t trick the extension into executing their code in a highly privileged context. However, it is still possible to find vulnerabilities with regards to the inter process communication.

1 //default CSP 2

3 "content_security_policy": script −src ’ self ’ ; object−src ’ self ’ ;

Listing 5.14: The default settings for the CSP enforced by Firefox.

It is unnecessary to look for execution sinks first so this analysis will focus on finding the content script that is in charge of communicating with the web pages. The manifest file specifies that the

(26)

content_script.js file should be inserted in every web page. The analysis tool detects one listener in charge of handling the requests sent from browser elements and web pages, see Listing5.15

1 //content_script.js 2

3 chrome.runtime.onMessage.addListener(function(request, sender, sendResponse) { 4 //console. log (’ content script runtime.onMessage: ’, request .action );

5 switch (request.action) { 6 case ’update_shortcuts’: 7 bindShortcuts(request); 8 break; 9 case ’init_entire_capture’ : 10 initEntireCapture (); 11 break; 12 case ’init_selected_capture ’ : 13 initSelectedCapture (); 14 break; 15 case ’scroll_next ’ : 16 scrollNext (); 17 break; 18 case ’destroy_selected ’ : 19 removeSelected(); 20 break; 21 case ’ restorebar ’ : 22 restorePosition (hostname); 23 restoreFixedElements();

24 var searchbar = document.getElementById("searchbar"); 25 if (searchbar != null ) {

26 searchbar. style . display = ’block ’ ; 27 document.body.id = ’searchbarshow’; 28 }

29 break;

30 case ’finishAutoSave’ :

31 var message = "The screenshot has been saved in " + request.path + ’.’; 32 notification .show(’success’ , message);

33 break; 34 }

Listing 5.15: A part of the message listener function in the content_script.js file which is in charge of dispatching the requests from web pages and browser elements.

This pattern of calling another function from the listener by providing different tags in the message is similar to the pattern found in the Adblock for Firefox extension. Because none of the messages are sanitized or filtered, it is possible for an attacker to invoke any of the commands described in the switch statement which is found in lines 5 through 33 in Listing5.15.

For example, a request with the action finishAutoSave will be handled in lines 30 through 33. The extension will create a notification element in the browser and fill it with the text provided by the request. If this function is called too often, the user’s browser can freeze and the computer can even crash because too many resources are needed to process all the notification messages.

While this exploit is a minor bug, it could have been avoided by checking the contents of the sender argument which is passed to the listener function on line 3 in Listing5.15. If the sender is unknown or if the message doesn’t originate from the extension itself, the request should be ignored. While the exploit does not allow an attacker to gain access to a highly privileged part of the extension, it is still possible to gain control over the content script. This extension doesn’t sanitize the messages sent between processes, which makes it possible to exploit the messaging system and gain limited control over the extension’s behavior.

(27)

Chapter 6

Conclusion

This paper describes a tool that can automatically detect privilege escalation vulnerabilities in Firefox WebExtensions by analyzing the AST. These privilege escalation vulnerabilities are data flows from a low privilege process to a different, more privileged process. A literature study of the WebExten-sion documentation showed that one of the ways for data to reach another process is by means of messages. With the information found in previous research[1, 6, 24], a motivating example was de-signed to demonstrate how the communication functions in the WebExtension API can be exploited for privilege escalation attacks.

To prove a static analysis was sufficient to detect these vulnerabilities, a literature study on the detection of vulnerabilities in JavaScript extensions and web applications was conducted. The results of this literature study were used to design and implement a static analysis tool that can automati-cally detect and report vulnerable statements in the source code. Apart from reporting the vulnerable statements, the tool is also able to trace the flow of information to and from vulnerable statements. This allows the tool to determine whether an extension is vulnerable to privilege escalation attacks by means of messages.

To prove the correctness of the analysis tool, a case study on the Adblock for Firefox extension was conducted. This case study demonstrated how a developer can use the tool to analyze their extension and detect potential vulnerabilities. This case study showed that it was possible to send a callback function from a web page to a background script. The background script then uses the function as an argument for an API call. Another case study was done on the Awesome Screenshot Plus extension to demonstrate other vulnerabilities can also be found in extensions that do not allow the execution of dynamic code.

The tool was able to detect data flows from an insecure source to another process with different privileges. Both case studies had a data flow from a web page to a dispatch function in the extension. Exploiting this data flow could influence the behavior of the extension in a negative way. Which leads to the conclusion that Firefox WebExtensions are vulnerable to privilege escalation attacks by means of messages between processes. However, the CSP can restrict the execution of dynamic code. This may limit the damage a compromised extension can do.

(28)

Chapter 7

Discussion

One of the difficulties of this research was finding a large set of data to prove the correctness the tool. Only 57 out of the top 376 Firefox extensions were ported to the WebExtension framework. Out of the ported extensions, only one allowed for the execution of dynamic code by means of eval or similar statements. This meant there was only one example to demonstrate privilege escalation vulnerabilities in which the attacker can execute their own code in another context.

It is reasonable to assume this tool will be able to find similar vulnerable extensions in the future because a recent study on privilege escalation attacks in Google’s Chrome browser successfully found vulnerable extensions[6].

Another point of interest were the opt-out CSP policies enforced in the new framework. This study found that they are successful at preventing XSS attacks by means of dynamic evaluation of string objects. According to Richards, et al.[24], and Weichselbaum, et al.[31], eval and other dynamic execution mechanisms were still used very often in web applications. In contrast to their results, this study found that only one out of 57 WebExtensions allowed for the use of eval and similar statements. In addition to the opt-out CSP policies, this study found none of the downloaded WebExtensions used the eval statement.

Finally, Akhawe, et al.[1] and Weichselbaum, et al.[31] claimed the CSP is often ignored which can compromise other security measures taken in the code to prevent attacks. Having the opt-out policy forces developers use it, even if they forget to make it. If developers want to allow any statements that are vulnerable to XSS attacks, they have to explicitly declare this in the CSP.

(29)

Chapter 8

Future work

While the static analysis was shown to be able to detect potential inter-process communication vul-nerabilities, there is still room for improvement. First of all, the current version of the tool reports false positives. This means a developer has to manually sift through the output in order to find any real vulnerabilities.

To increase the accuracy of the vulnerability detection, it may be necessary to also consider which processes communicate with each other and focus on the messages sent between these processes. By allowing the tool to also consider the path from one process to another process, only the paths that can lead from a web page to the background script are reported. This can be achieved by combining the source code of all scripts in an extension in one file and then analyzing the resulting AST of this file. Because this method could prune out communications that don’t end up at the privileged background script, it will have a lower false positive rate.

Another way to increase the accuracy is by adding both dynamic and blended analysis to the process. By combining the results of both the dynamic and the static analysis, the amount of detected vulnerabilities will be higher than when the analysis uses just one type of analysis[30].

The amount of false positives can also be lowered by checking whether the vulnerable statements are already being sanitized. Previous research showed it is possible to determine the possible string values of dynamic objects in PHP[32]. By modifying the approach to also consider the contents of messages passed between different processes, it might be possible to determine whether messages are sanitized and whether they actually need to be sanitized.

Another way to increase the accuracy is by providing proof of concept exploits for the vulnerabili-ties. This will allow for a way to verify whether the vulnerability can be exploited and to demonstrate the severity of the vulnerability. This would require a more dynamic approach which supplies the extension with a web page that sends messages to the vulnerable content scripts and monitor what other scripts are influenced by the messages.

Finally, because this tool was built on the assumption that usage of eval and inline JavaScript execution was still prevalent, other vulnerabilities were ignored. That means the current version of the tool only checks for vulnerabilities in which dynamic code can be executed in a privileged context. To cover different types of vulnerabilities, like being able to read or even write to cookies[6] a more extensive analysis has to be designed. This would mean the tool has to differentiate between the API calls made within the extension. These API calls can be used to categorize the vulnerabilities depending on the resources they can access through the API calls. This will make the feedback given to the developers more clear on what exactly the extensions are vulnerable for.

(30)

Bibliography

[1] Devdatta Akhawe, Prateek Saxena, and Dawn Xiaodong Song. Privilege separation in html5 applications. In USENIX Security Symposium, 2012.

[2] Sruthi Bandhakavi, Nandit Tiku, Wyatt Pittman, Samuel T. King, P. Madhusudan, and Mar-ianne Winslett. Vetting browser extensions for security vulnerabilities with VEX. Commu-nications of the ACM, 54(9):91, sep 2011. doi:10.1145/1995376.1995398. URL https: //doi.org/10.1145%2F1995376.1995398.

[3] Adam Barth, Joel Weinberger, and Dawn Xiaodong Song. Cross-origin javascript capability leaks: Detection, exploitation, and defense. In USENIX Security Symposium, 2009.

[4] Adam Barth, Adrienne Porter Felt, Prateek Saxena, and Aaron Boodman. Protecting browsers from extension vulnerabilities. In NDSS, 2010.

[5] Dimitri Belfor. Static analysis tool. https://github.com/DBelf/these, 2017.

[6] Stefano Calzavara, Michele Bugliesi, Silvia Crafa, and Enrico Steffinlongo. Fine-grained detection of privilege escalation attacks on browser extensions. In Programming Languages and Systems, pages 510–534. Springer Berlin Heidelberg, 2015. doi:10.1007/978-3-662-46669-08_21. URL

https://doi.org/10.1007%2F978-3-662-46669-8_21.

[7] Arjun Guha, Matthew Fredrikson, Benjamin Livshits, and Nikhil Swamy. Verified security for browser extensions. In 2011 IEEE Symposium on Security and Privacy. IEEE, may 2011.

doi:10.1109/sp.2011.36. URL https://doi.org/10.1109%2Fsp.2011.36.

[8] Daniel Hedin and Andrei Sabelfeld. Information-flow security for a core of JavaScript. In 2012 IEEE 25th Computer Security Foundations Symposium. IEEE, jun 2012.

doi:10.1109/csf.2012.19. URLhttps://doi.org/10.1109%2Fcsf.2012.19.

[9] Daniel Hedin, Arnar Birgisson, Luciano Bello, and Andrei Sabelfeld. JSFlow. In Proceedings of the 29th Annual ACM Symposium on Applied Computing - SAC ’14. ACM Press, 2014.

doi:10.1145/2554850.2554909. URL https://doi.org/10.1145%2F2554850.2554909.

[10] Ariya Hidayat. Esprima, 2017. URLhttp://esprima.org/.

[11] Foundeo Inc. Content security policy, 2016. URLhttps://content-security-policy.com/.

[12] Dongseok Jang and Kwang-Moo Choe. Points-to analysis for JavaScript. In Proceed-ings of the 2009 ACM symposium on Applied Computing - SAC ’09. ACM Press, 2009.

[13] Vineeth Kashyap, Kyle Dewey, Ethan A. Kuefner, John Wagner, Kevin Gibbons, John Sarracino, Ben Wiedermann, and Ben Hardekopf. JSAI: a static analysis platform for JavaScript. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2014. ACM Press, 2014. doi:10.1145/2635868.2635904. URL https: //doi.org/10.1145%2F2635868.2635904.

(31)

[14] Yin Liu and A Milanova. Static information flow analysis with handling of implicit flows and a study on effects of implicit flows vs explicit flows. In 2010 14th European Conference on Software Maintenance and Reengineering. IEEE, mar 2010. doi:10.1109/csmr.2010.26. URL

https://doi.org/10.1109%2Fcsmr.2010.26.

[15] Bill McCloskey. Multiprocess firefox, December 2013. URL https://billmccloskey. wordpress.com/2013/12/05/multiprocess-firefox/.

[16] Mozilla Developer Network. Ipdl tutorial, January 2016. URL https://developer.mozilla. org/en-US/docs/Mozilla/IPDL/Tutorial.

[17] Mozilla Developer Network. Anatomy of a webextension, April 2017. URLhttps://developer. mozilla.org/en-US/Add-ons/WebExtensions/Anatomy_of_a_WebExtension.

[18] Mozilla Developer Network. Introduction to the dom, July 2017. URL https://developer. mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction.

[19] Mozilla Developer Network. Content scripts, July 2017. URL https://developer.mozilla. org/nl/Add-ons/WebExtensions/Content_scripts.

[20] Mozilla Developer Network. Firefox add-ons, 2017. URLhttps://addons.mozilla.org/en-US/ firefox/.

[21] Mozilla Developer Network. Message manager overview, April 2017. URL https: //developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Message_Manager/ Message_manager_overview.

[22] Stefano Di Paola, Mario Heiderich, Frederik Braun, and Guiseppe Trotta. Domxss wiki. https: //github.com/wisec/domxsswiki/wiki, 2016.

[23] Gregor Richards, Sylvain Lebresne, Brian Burg, and Jan Vitek. An analysis of the dy-namic behavior of JavaScript programs. ACM SIGPLAN Notices, 45(6):1, may 2010.

[24] Gregor Richards, Christian Hammer, Brian Burg, and Jan Vitek. The eval that men do. In Lecture Notes in Computer Science, pages 52–78. Springer Berlin Hei-delberg, 2011. doi:10.1007/978-3-642-22655-7_4. URL https://doi.org/10.1007% 2F978-3-642-22655-7_4.

[25] Jesse Ruderman. Same-origin policy, 2016. URL https://developer.mozilla.org/en-US/ docs/Web/Security/Same-origin_policy.

[26] Bassam Sayed, Issa Traore, and Amany Abdelhalim. Detection and mitigation of malicious JavaScript using information flow control. In 2014 Twelfth Annual International Conference on Privacy, Security and Trust. IEEE, jul 2014. doi:10.1109/pst.2014.6890948. URLhttps: //doi.org/10.1109%2Fpst.2014.6890948.

[27] Manu Sridharan, Julian Dolby, Satish Chandra, Max SchÃďfer, and Frank Tip. Correlation tracking for points-to analysis of JavaScript. In ECOOP 2012 – Object-Oriented Programming, pages 435–458. Springer Berlin Heidelberg, 2012. doi:10.1007/978-3-642-31057-7_20. URL

https://doi.org/10.1007%2F978-3-642-31057-7_20.

[28] Yusuke Suzuki. escope. https://github.com/estools/escope, 2013.

[29] Jorge Villalobos. The road to firefox 57 — compatibility milestones, February 2017. URL https://blog.mozilla.org/addons/2017/02/16/ the-road-to-firefox-57-compatibility-milestones/.

[30] Shiyi Wei and Barbara G. Ryder. Practical blended taint analysis for JavaScript. In Proceedings of the 2013 International Symposium on Software Testing and Analysis - ISSTA 2013. ACM Press, 2013. doi:10.1145/2483760.2483788. URLhttps://doi.org/10.1145%2F2483760.2483788.

(32)

[31] Lukas Weichselbaum, Michele Spagnuolo, Sebastian Lekies, and Artur Janc. CSP is dead, long live CSP! on the insecurity of whitelists and the future of content security policy. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security - CCS´16. ACM Press, 2016. doi:10.1145/2976749.2978363. URL https://doi.org/10.1145%2F2976749. 2978363.

[32] Fang Yu, Muath Alkhalaf, Tevfik Bultan, and Oscar H. Ibarra. Automata-based symbolic string analysis for vulnerability detection. Formal Methods in System Design, 44(1):44–70, sep 2013.

Inter-process Communication Vulnerabilities In Firefox Extensions