Client-side web security

To address attacks such as XSS, Magecart and other card skimming exploits found in modern eCommerce environments, the use of client-side web security methods is beginning to emerge as a particularly useful practice.

Obviously, enterprise teams should integrate client-side protections with desired server-side countermeasures to ensure a full risk management profile (e.g., the client-side is a poor selection point to stop denial of service).

Several standards-based client-side security approaches have begun to mature that are worth examining from the perspective of website security and protection of browser sessions from malicious exploits. The best client-side security platforms automate implementation of these standards-based controls with emphasis on simplicity of administration. A typical, representative platform is used to demonstrate necessary client-side security controls.

Content security policy

To understand client-side security platforms, it helps to first explore the specifics of a standard approach known as a content security policy (CSP). This is a standard that is designed to address several types of web breaches such as cross-site scripting, click-jacking and form-jacking (all described earlier in this article series). CSP is also designed to reduce the risk of client-side malware injected from an infected advertising ecosystem.

CSPs are implemented as standard directives involving HTTP headers or page tags that specify which domains, subdomains, and resources a browser can load from a website. CSP use is consistent with the browsers any user would likely use including Chrome, Firefox, Safari, and Edge. The goal is that if malicious code is resident on a site, then visitors to that site would be prevented by the CSP from being directed to the hacker’s domain.

Figure 1. Content security policy

The example shown above in Figure 1 is taken directly from the original W3 recommendation. The CSP code can be interpreted as follows: Each source expression represents the location where content of the type specified is allowed to be pulled. To illustrate this whitelist security operation, consider that the self keyword-source designation, in the example above, represents the set of URIs in the origin as the protected website.

Companies like Google have rolled out CSP successfully and are using it to stop attacks against their web applications daily. However, CSP is deployed only lightly in most web application environments. The challenge with CSP implementation has been its complex administration. Tala Security researchers have found, for example, that roughly two percent of website operators in the top Alexa 1000 websites deploy the standard to prevent client-side attacks. Assisting with this administrative challenge is a primary motivation for client-side platforms.

Client-side security protection results from using CSP can websites can be quite impressive. Here are some observed statistics from the Tala Security research team based on their experiences with client-side security support:

• Images – The average website in the Alexa 1000 loads images from roughly sixteen different external domains. The img-src directive in CSP blocks images from any unwanted or potentially malicious sites.
• Stylesheets – The average website in the Alexa 1000 loads stylesheets from roughly two different external domains. The style-src directive in CSP blocks stylesheet loads from any unwanted or potentially malicious sites.
• Fonts – The average website in the Alexa 1000 loads images from roughly one-and-a-half different external domains. The font-src directive in CSP blocks font downloads from any unwanted or potentially malicious sites.
• Media – The average website in the Alexa 1000 loads images from different external domains. The media-src directive in CSP blocks font downloads from any unwanted or potentially malicious sites.

Subresource integrity

An additional applicable cyber security standard from the World Wide Web Consortium (W3C) is known as subresource integrity (SRI). This standard is designed to validate resources being served up by any third party on a visited website. Such third parties include content distribution networks (CDNs), where it has not been uncommon to find malicious code being offered up to unsuspecting websites.

SRI is implemented through cryptographic hash functions which finger-print JavaScript being offered by third parties. Browsers can then fetch a resource, check the cryptographic hash value – which include the location of the resource, and then make a policy decision about whether to accept the resource. This capability is supported in all important browsers, and significantly reduces the risk of malware from third party actors.

Client-side security platform

Client-side security platforms will make use of both CSP and SRI to provide effective client-side protections. The goal of these platform is to provide policy-based mitigation of fine-grained behavior for third-party sources where content is being served. Client-side platforms can then watch for any data collection suggestive of the attacks used by Magecart (and similar groups).

The client browser mitigation should be implemented based on artificial intelligence-based classification and learning. The software should install quickly and easily. Commercial platforms should support implementation for many target environments including Apache Nginx, IIS, NodeJS, and others. Performance and latency impacts should also be essentially non-existent and non-affecting of the user experience. Specific capabilities included in a commercial platform should include:

• Indicator evaluation – The selected platform should be designed to evaluate many different indicators of a web page’s architecture to analyze code, content, connections, and data exchange.
• Behavioral and risk modeling – The platform should include support for analysis to inform a behavioral and risk modeling task designed to highlight normal behavior and expose vulnerabilities.
• Operational improvement – Insights gained from the platform evaluation and modeling should be made available to help prevent client-side attacks such as XSS, Magecart, and the like.

The operation of world-class client side security platforms should include an on-going interaction between four different activities: Build, Monitor, Block, and Respond. The connection flow between these different lifecycle phases is depicted below.

Figure 2. Commercial client-side security lifecycle

Information model

Client-side security platforms should implement some type of information model that can be used to analyze the different behaviors on pages from the customer’s website to be protected. The security objective for such extraction should be to explicitly identify any sources of code and content on these web pages, as well as to find any data exchange support options that could involve sensitive data.

The resultant behavioral information model will thus provide a functional baseline on which to perform the necessary client-side risk management. The goal obviously should be to determine in real-time whether the site is vulnerable to attacks, third-party insertion, or other advanced breaches. As one would expect, performance of such behavioral modeling and protection in real-time complements any existing server-side security tools.

Contributing author: Aanand Krishnan, CEO, Tala Security.