People's Newsroom


Client-side mitigation techniques can be implemented at various levels. Since the previous chapters have only discussed the use of browser add-ons, we first take a step back and present a broad overview of the different strategies for implementing a client-side mitigation technique.


A first approach for implementing a client-side mitigation technique is to build a traditional OS-level application, which listens for interesting events, such as network traffic going out. The operating system offers hooks for a wide variety of system operations, such as network activity or file system access, allowing an application to run its code when such an event occurs. This approach is commonly used by antivirus products to detect a virus the moment a file is accessed.

One of the main advantages of using OS-level hooks is the independence of the countermeasure from the client application, which can be a browser, a game, or anything else running on top of the OS. An additional advantage of these OS-level hooks is the capability to operate on multiple applications simultaneously, enabling the enforcement of a cross-application security policy. The price of this flexibility is paid when a hook is triggered, since the invoked code needs to process low-level data, such as network packets, which requires a significant amount of effort. Additionally, at the level of the OS, all context information from the client application that generated the data is lost, which may be a limiting factor to implementing the security policy at hand. 


Using a client-side proxy to implement a network-based client-side mitigation technique is a commonly used approach. The client applications send their network traffic through a proxy, a feature that is supported by most applications nowadays. The proxy enforces its security policy by inspecting and modifying the traffic that passes through. Proxies can be developed as client-side applications running on the same machine as the client application or can be deployed on a separate device in the local network. Several research proposals successfully use the proxy-based approach to protect the client application against cross-site request forgery, session hijacking, and SSL stripping.

The proxy-based implementations still have the advantage of being independent of the client application, allowing a free choice of browser. Additionally, they can intercept the traffic from multiple applications, allowing the cross-application enforcement of a security policy. Compared to an application using OS-level hooks, proxies can also operate on a specific protocol, requiring only limited effort to process the network traffic, for example into HTTP requests. One important disadvantage remains the lack of context information, which may complicate the enforcement of a security policy, for example when the user is using two separate browsing sessions. Additionally, proxy-based approaches are restricted to network-based security mechanisms, which is, however, a less significant restriction in the context of the Web.


A third approach directly integrates the mitigation technique in the client application, typically a browser. The client application’s code is modified to integrate the security mechanism, enforcing the security policy from within the application. This approach is often used to implement complex security mechanisms, such as an architecture for least-privilege isolation of components in a Web page, the enforcement of information flow control for JavaScript, or the binding of cookies to TLS channels.

The most significant advantage of directly implementing the security mechanism in the target application is the high degree of freedom. If necessary, every aspect of the application can be modified to ensure complete mediation when enforcing the security policy. Additionally, since the mitigation technique is implemented within the client application, it can access all the required context information, such as the Web page and its window, which supports the enforcement of fine-grained security policies. One disadvantage of customizing an application is the high degree of complexity of modifying a browser’s codebase.  Additionally, unless the mitigation technique will be adopted by browser vendors and integrated into mainstream browsers, wide-scale deployment across the Web is practically impossible.


Users can install browser add-ons to modify and extend the default browser behavior. In this scenario, browsers offer hooks to internal browser events, to which an add-on can register custom handlers. For example, exposed hooks allow the interception of network requests and responses, the inspection of the DOM after loading, etc. Additionally, browsers expose a set of features through APIs, allowing add-ons to read and write files, send custom network requests, access the page’s contents, etc. Browser add-ons are a quick and easy way to implement a research prototype, not only used by the work presented in the previous chapters, but also by a proposal to force HTTPS connections, by an approach to offer Web application integrity, and by an alternative approach to prevent CSRF attacks.

An important advantage of a browser add-on is the lightweight development process, enabling the quick validation of a research idea. Following up on good research ideas, browser add-ons can be used to build prototypes, as well as marketable products, as illustrated by CsFire. Since add-ons are essentially part of the browser, they can use the available context information to enforce a fine-grained security policy. This brings us to one of the disadvantages of browser add-ons: they are limited to the APIs offered by the browser. As we will discuss further in this section, Firefox offers a wide variety of APIs, even allowing to run external programs, while Chrome keeps the APIs very tight, preventing an add-on from breaking out of the browser process’ sandbox, resulting in a more secure system.


A final approach to implement a client-side security mechanism is to instrument the Web application with a security mechanism, that will be executed by the browser. In this scenario, the code of the security mechanism is embedded in the application’s pages, script files, and other Web content that will be distributed to the client. This approach is often used to implement technologies that isolate certain components from the application.

The main advantage of this approach is the lack of any installation procedure at the client-side, allowing the security mechanism to be distributed to all clients at once. As this technique is an instantiation of an inline reference monitor, it also shares the challenges of inline reference monitors to achieve complete mediation, and avoid tampering with the code of the security mechanism. Additionally, the code of the security mechanism is restricted to the same privileges as the application code, which imposes limits on cross-origin interactions.

Back to top button