People's Newsroom


An important trend in client-side Web security is the rise of server-driven client-side security policies. These policies have been developed alongside the line of research on autonomous client-side mitigation techniques, both in research, as illustrated by the WebSand project, as in practice, as illustrated by examples such as Content Security Policy. These server-driven security policies are delivered by the server, where the desired security properties and underlying application structure are known and are enforced by the browser, the most optimal location for enforcing client-side security policies.

Server-driven client-side security policies have emerged from a constantly evolving security process, which started with generic browser security policies, such as the Same-Origin Policy, which were applied to all applications, without exceptions or customizations. As the server-side processing component of Web applications became more advanced, Web security mechanisms and countermeasures against concrete attacks were to be implemented at the server-side. Well-known examples are token-based approaches against CSRF attacks, or input and output sanitization against injection attacks. While these security mechanisms initially required a significant amount of effort from the developer, the developer community quickly caught up, offering easy-to-use libraries and out-of-the-box support in popular development frameworks. Unfortunately, as we witness up until today, merely offering support for the appropriate security technology is not sufficient to secure the Web. Many developers are not aware of all the security technology they need to incorporate, and legacy applications are often not updated to include the optimal security solutions, due to various reasons, such as technical difficulties or a lack of interest.

In response to these applications remaining vulnerable, while adequate mitigation techniques were available, a movement of autonomous client-side countermeasures started to offer users the protection they desired. A popular example is the NoScript browser add-on, whose main feature is preventing JavaScript from executing, and is installed by more than two million Firefox users. Autonomous client-side countermeasures operate without the support of the applications they protect and need to be able to support all applications their typical user visits, which is an unbounded subset of the entire Web. In order to achieve maximum compatibility, these countermeasures push the limit of what is possible, while maintaining the delicate balance between usability and security. This presents a difficult challenge, as it is not always possible to make a correct security decision without additional server-side information. For example, from CsFire’s point of view, a legitimate cross-origin request and a carefully crafted CSRF attack technically look exactly the same, with the only difference between them being that the former is intended by the application, and the latter is not. Another example is the heuristic algorithms to determine whether a specific cookie value is a session identifier or not, which are not perfect but require manual intervention to improve.

As the importance of the client platform increased, new client-side countermeasures were introduced to enforce security policies provided by the serverside application, which is best positioned to provide information about the intended behavior, the important tokens, and the required resources. Essentially, autonomous client-side countermeasures already supported this practice in the form of centrally administered policy databases, to minimize the impact of potential false positives. The first example of an application-driven security policy is the HttpOnly and Secure cookie flags, telling the browser which cookies can be made accessible from JavaScript, and which cookies can be sent over a non-secure channel. Another, more complex example is Content Security Policy, a policy initially intended to combat script injection attacks, which is now rapidly evolving into the all-inclusive client-side security policy, with future features such as UI security directives and Entry Points. An often-heard critique on server-driven client-side security mechanisms, such as the sandbox attribute or Content Security Policy, is that they only mitigate part of the attacks, lack a certain level of fine-graininess, and do not provide an airtight solution against a specific attack.

Taking into account that most attacks do in fact originate from server-side vulnerabilities, such as a failure to properly sanitize input and output, this seems an unfair evaluation. These countermeasures are intended to give a security-conscious Web developer an additional tool to squash attackers that manage to evade the server-side defenses, as well as to add a layer of protection to a legacy application, which can not easily be modified to incorporate the appropriate defenses. The seemingly secondary role of server-driven client-side mitigation techniques should not be mistaken for a sign of inutility, as they are essential for deploying an in-depth defense strategy. Applying multi-layered defense attributes to well-established security principles, and effectively helps stop an attacker who has managed to circumvent alternative protection mechanisms.

Back to top button