People's Newsroom


Since the focus of this dissertation lies on add-on-based implementations, we elaborate on the capabilities that are available to add-ons, and how these differ between the two most used platforms, which are Mozilla Firefox and its mobile counterpart, Fennec, and Google Chrome’s desktop version of the browser. Browsers expose numerous feature-rich APIs towards browser add-ons, granting these add-ons rich mediation power, deep-reaching access to the loaded pages, and the capability to extend the browser’s UI. In summary, these three capabilities are necessary to build a client-side mitigation technique, for the following reasons:

Mediation Power. Add-ons possess rich mediation power through the browser-provided hooks. A commonly used example of these hooks is the network events, where HTTP requests and responses are intercepted, allowing an add-on to inspect and modify the traffic, or to block a request from leaving the browser.

Page Access. Add-ons can access the contents of a loaded Web page, allowing them to not only inspect the DOM tree of the document but also to modify the tree by injecting and deleting nodes. As an extreme example, the Greasemonkey add-on even allows users to define their own scripts to manipulate the DOM of certain sites, thereby introducing new security vulnerabilities.

UI Modifications. Add-ons have the possibility to modify and extend the browser’s UI, enabling them to interact with the user using additional toolbars, buttons, menu items, etc. How these capabilities are exposed depends on the browser’s underlying architecture, which vastly differs between browsers. Firefox supports privileged add-ons, which not only have access to a large set of browser-provided APIs but also to the browser’s internals and operating system resources, enabling capabilities such as reading/writing files, spawning new processes, etc.

In Firefox, add-ons all live within the same namespace and can define core components with an API to be exposed to other add-ons, as well as to scripts that interact directly with Web content. In the recently introduced JetPack model, the addon can also choose to adopt a more modular model, offering some isolation and restrictions, even though the rich APIs remain accessible if desired. Concretely, add-ons in Firefox are subject to very few limitations, and can easily share their functionality among core components and scripts interacting with Web content. Chrome is based on the principles of least privilege, isolated worlds, and permissions. Add-ons have a core component, which runs separately from content scripts, which interact with actual Web content. Communication between both contexts is only available through the Web Messaging API.

Additionally, add-ons all have a distinct namespace and are isolated from each other. The browser APIs offered by Chrome is more limited than the Firefox APIs, and do not support reaching out of the browser sandbox, into the OS. Furthermore, Chrome add-ons have to explicitly request a set of permissions for a determined set of Web sites (wildcards are allowed) upon installation. Without the necessary permissions, several APIs become inaccessible, preventing an add-on from escalating its power within the browser. We initially implemented CsFire on the Firefox platform, and later expanded support towards Google Chrome as well. Both platforms offer several hooks to inspect and manipulate network requests as they leave the browser, allowing the enforcement of CsFire’s security policy. To optimize the use of shared code between both platforms, CsFire’s core functionality is implemented in a platform-independent manner and uses platform-specific adapters towards the browser-provided APIs. These adapters invoke the correct APIs, register events to the correct hooks, and translate between generic objects and browser-specific objects, such as the internal representation of a URI. Clearly, the features offered by Firefox open a wide range of possibilities for browser add-ons, but these possibilities come at the price of security guarantees, which are virtually non-existent in the Firefox model. Chrome, on the other hand, confines the add-ons within the browser, preventing them from compromising the client device running the browser.

In our experience developing numerous browser add-ons for both Firefox and Chrome, we can conclude that the Chrome platform is the easiest to get started with. Chrome offers clear APIs and a straightforward system to register to internal browser events, as well as a developer console for inspecting and debugging the add-on code in real-time. Firefox, on the other hand, offers a more complex system to register to browser events, and the internal browser APIs are much more complicated. On the plus side, Firefox offers significantly more freedom, allowing an add-on to easily call native libraries or even execute arbitrary programs on the operating system. Unfortunately, Firefox does not offer easy-to-use debugging tools, making the development process more difficult.


Building research prototypes also involves an extensive evaluation, to show the benefits of the proposed mitigation technique, as well as the potential impact. We report on our experiences with both large-scale evaluations on the Alexa top 1,000,000 and smaller-scale evaluations on the Alexa top 1,000. One aspect of evaluating a client-side mitigation technique is determining its effectiveness at mitigating the targeted attacks. For our prototypes, we have built test cases, which effectively attempt to carry out the attack in a lab setup, allowing us to verify whether the mitigation technique actually works or not. For CsFire, we even built a full security benchmark, listing all CSRF attack vectors in the HTML and CSS specifications. Such a benchmark is beneficial for the security evaluation of a prototype, allowed us to perform rigorous testing before releasing a new version, and has been subsequently used in a master’s thesis on building an automated platform for testing the effectiveness of client-side countermeasures.

A more challenging aspect of evaluating autonomous client-side mitigation techniques is determining the compatibility with current sites. Since these countermeasures operate independently from the Web applications loaded in the browser, they must aim for complete compatibility. While this goal is practically never fully achieved, all evaluations do focus on the compatibility aspect, carefully discussing the false positives that occur. Gathering data, both about the presence of vulnerabilities as the effectiveness of the countermeasure at hand, is extremely important, but also very challenging. For example, the experimental evaluation of CsFire is only possible because of the cooperation of numerous subjects who willingly recorded information about their browsing traffic. For Serene, the use of heuristics to identify session identifiers was necessary, which has inescapably led to false positives.

Additionally, detecting the presence of vulnerabilities like CSRF requires interaction with the Web application at the server-side, not something to be run in an automated fashion on a large scale, as actions may have unexpected consequences. Similarly, wide-scale detection of session fixation and session hijacking vulnerabilities requires automation of Web application’s authentication processes, not a trivial task. Being able to explore the authenticated parts of Web applications would be a breakthrough for the field of Web security, both for exploratory research efforts as for the evaluation of newly proposed countermeasures. Automating arbitrary authentication procedures, requiring dedicated, application-specific accounts is a strong challenge. A slightly weaker, but almost equally useful challenge can take advantage of the prevalence of social networks, as numerous applications nowadays offer social login systems, where a single social networking account grants access to a wide variety of applications.

An automated discovery process of applications that support social login, should enable the automated, authenticated crawling of such applications. Since evaluating a client-side countermeasure generally involves visiting a large number of pages, automating the procedure is recommended. Specifically for a prototype built as a browser add-on, the evaluation setup requires control over an actual browser to visit the pages. Depending on the number of pages that need to be visited, the evaluation setup can run on a single machine in a matter of days or may require a more elaborate, distributed setup. We have used both, a single-machine setup for the evaluation of TabShots on the Alexa top 1,000, and a distributed setup for Serene, where we visited the Alexa top 1,000,000. Fortunately, ample tools are available to control the browser remotely, passing it URLs of pages to visit.

One approach is to directly invoke the browser executable, and pass it a URL, as we did with Serene. A second approach is to use an add-on, such as ChickenFoot, to instruct the browser to visit a list of URLs, an approach we followed with TabShots. A third approach is to use a browser automation framework, such as Selenium, to actually control the browser and inspect the resulting page. We used the latter approach to implement a set of unit tests for CsFire, both to evaluate its effectiveness against a large amount of CSRF attack vectors, and to perform pre-release unit and regression tests on every subsequent release, where additional features were added. Finally, from our experience in demonstrating and describing the use of add-ons for building prototypes, we have learned that the nuances of add-ons and the differences between add-on and browser customizations are not always fully understood. Therefore, the use of add-ons to build research or demonstration prototypes warrants a careful explanation of the drawbacks and benefits.

Back to top button