Client-side Attacks: What They Are and How to Prevent Them

February 16, 2021 - Ensighten

The biggest risk of a client-side attack is a major data breach. According to the Ponemon 2020 Data Breach Cost Study, the average data breach fines and recovery costs total at $3.86 million on average. The costs escalate in more highly regulated industries such as Healthcare and Financial Services.

 Hackers innovate and continuously move to exploit the point of least resistance. The web browser has increasingly come under attack and requires organizations to extend their approach out to the web browser to mitigate risks.

 

What are client-side attacks?

There are two main components to a website or app: server and client. The server side stores code and data and processes operations and requests. The client side is where the web application comes together and is rendered within a browser.

Traditionally, hackers have targeted the server side, employing methods designed to break in and steal assets. Over time, organizations have leveraged origin-focused security products to safeguard data and assets, but cybercriminals are continuously moving to exploit the point of least resistance. Therefore, they have since turned their attention to a different target: the application or web browser that runs on the endpoint or client. Hackers are exploiting client-side weaknesses to steal sensitive and financial customer data for sale on the dark web.

 

The browser is the client

Approximately 50 percent of the world’s Internet traffic is delivered through a web browser. The browser interprets and runs this code to deliver the experience when the user accesses the website. 

When visiting a website, you see text, pictures and videos and have the ability to create accounts, browse catalogs, customize products, make purchase accounts and more. Much of the website functionality relies on browser capabilities, with the web browser bringing together website code and processing this code into a highly immersive experience.

 

JavaScript is the browser

JavaScript is used by 97 percent of websites and web applications worldwide. Development teams use their own JavaScript code (first party) as well as tap into other code sources (third party), including open source (e.g., jQuery, AngularJS, React) and third-party technologies that include JavaScript components (e.g., WordPress, Drupal, Magento) to accelerate the process. While use of JavaScript brings many benefits, it also introduces substantial and often overlooked or misunderstood risks.

 

JavaScript is powerful and risky

JavaScript can implement complex features on a web page, including manipulating page elements and reading entered data. When a browser accesses a website, it downloads all of the code and content from the remote servers, both the site owner’s servers (within your control) and any third-party libraries used (outside of your control). After downloading all code and content, the browser presents the website to the user. If an attacker can hide malicious code in any of the downloaded resources, first or third party, the browser will process and run it. For this reason, security and compliance stakeholders take special care to inspect and validate JavaScript code before moving it into production.

Open source and first-party JavaScript vulnerabilities

Several JavaScript vulnerability tools are available to inspect and validate code and search for known vulnerabilities. This is an important step to take but it falls short of mitigating JavaScript risks. First, a 100 percent vulnerability find and fix rate, while desired, is hard to attain. Vulnerabilities can be missed. Second, this inspection only validates JavaScript code in your control that your team developed. It does not mitigate the risks of the JavaScript code that comes from external sources – your partners in your web supply chain.

Web supply chain JavaScript vulnerabilities - you are what you include

The web supply chain is a mashup of third-party code that comes from technology partners (e.g., ecommerce platform) and third-party service scripts (e.g., analytics, chat bot, marketing). The web supply chain enhances the customer experience by adding important features. Keep in mind, however, that as partner technologies and services are added, so are thousands of pieces of third-party code. Each piece represents an increase of your attack service. The risk is further compounded when recognizing that many of these third parties have few resources dedicated to security.

A breach on a single piece of web supply chain code can covertly send malicious code down the supply chain into your website. And these pieces of third-party code have the same level of content and data access as the code built by your developers.

With the average website using 50-60 third-party components, hackers scour codebases and scripts looking for vulnerabilities and then target any organization making use of them. For example, the hacker group Magecart made its name after finding vulnerabilities in the popular component Magento, a component used by many thousands of online stores. By injecting rogue script code into this popular library, customer data was siphoned when users visited any of the online stores which utilized the component.  

What a single piece of malware code can do

Hackers have a wealth of open source, first-party and third-party codebases to target. A single piece of malware code tucked into the many thousands of lines of code can cascade across many organizations and customer bases. This was witnessed firsthand in 2018 when a hacker took control of a popular codebase called Event-Stream and injected malware into it designed to steal Bitcoin. This library turned out to be used by hundreds of thousands of businesses around the globe, leaving them vulnerable to criminal activity because of the usage of the component.

 

Common types of client-side data theft attacks

 The most common type of client-side attack is web skimming, an attack method used by hacker groups such as Magecart. The below video explains how a web skimming attack can take place.

 

Magecart

Web skimming/digital skimming

Formjacking

CSS injection

 

How to address client-side risks

While there are many third-party technologies and tools to help assess and mitigate client-side risks, strategies can be boiled down to a few fundamental approaches: browser security (CSP/SRI), behavioral detection, JavaScript analyzers, client-side data protection, and client-side data protection and privacy enforcement. 

Browser security

The browser adds layers of security that can be implemented by Dev/Sec/Ops teams – Content Security Policies and Subresource Integrity (SRI).

Content Security Policies (CSP)

CSP is a developer language for defining functionality restrictions of a website. Policies are developed to set constraints on content inclusion (e.g., images, scripts) bound to a specific set of origins. These policies are enforced on the browser side by CSP-enabled web browsers on a page-by-page basis. They are employed to help mitigate the risk of content (JavaScript, CSS) injection vulnerabilities and to control privileges with which web apps execute. When implementing CSPs, careful considerations should be taken including:

  • Browser support – CSPs are supported by all major browsers, though at varying levels. You can review supported CSP functionality across browsers here 
  • Proper configuration and efficacy – CSPs are no different than code and require specialized knowledge to design, create, test and maintain. Testing is critical given that CSPs can dramatically impact the functionality and performance of a web application. In fact, more than 92 percent of websites that use CSPs in enforcement mode are still vulnerable to content injection attacks according to research by University of Venice
  • Maintenance – on-going maintenance of CSPs are required as new browsers and CSP standards are released. Changes to web application functionality and embedded partner services also impact CSP capabilities
  • Staffing – CSP-based security can be constrained by development resources, skill sets, priorities and release cycles

Subresource Integrity (SRI)

SRI can be used to help ensure website content is protected if an attacker overtakes web files and attempts to conduct malicious changes. Based on hashes, Subresource Integrity can detect if JavaScript has been altered. The attacker may still be able to inject malicious code into a file, but the browser would not load the file. SRIs can be effective for static web pages and/or pages where JavaScript, including web supply chain code, is unlikely to change. 

Behavioral detection

Some client-side security approaches focus on detecting potential client-side attacks and alerting Dev/Sec/Ops teams. These tools provide telemetry to help troubleshoot and possibly remedy the situation. This approach involves instrumenting, analyzing and baselining normal web page behavior over a period of time and alerting teams to baseline variances that could suggest unusual (i.e., hacker) behavior. After an attack has been investigated and confirmed, these tools can facilitate development and deployment of security rules, often requiring the development of Content Security Policies (CSPs). Developer review and testing is required given the harmful effects a CSP can potentially have on overall website functionality and already deployed CSP code. 

JavaScript security analyzers

JavaScript security analyzers are security tools that perform code analysis on client-side applications. Analyzers can test for JavaScript security vulnerabilities, implementation issues, configuration errors and other risks that can be exploited by attackers. A major blind spot for analyzers is the web supply chain.  

Client-side data protection

This approach prioritizes proactive data protection based on an understanding of external domains and partners. Web application boundaries, including the web supply chain, are established up front for approved external domains. This is typically accomplished through allowlists. Client-side monitoring of the browser is then put in place to ensure browsers, web and mobile variants, only exchange content and data with these domains. The major advantages to this approach are fast time-to-protect, ease of use (non-development resources) and ease of maintaining.  

Client-side data protection and privacy enforcement

Building on the data protection approach, more advanced tools not only safeguard data and content against data theft, but also allow for the definition of more granular data sharing rules to further restrict the types of data (e.g., payment, social security number) that can be exchanged with allow-listed vendors. This allows companies to enforce user privacy preferences as well as comply with data protection regulations, such as the CCPA, GDPR and PCI DSS.

The Ensighten platform enables organizations to implement a client-side data protection and privacy enforcement approach. Learn more about the Ensighten platform.

Watch this video to learn how Ensighten prevents common client-side data breach methods, such as web skimming.

 

Learn more about Ensighten and our solution

Magecart blog

Learn more about the most talked about cyberattack group and how you can protect against Magecart attacks

Read Now

Online skimming guide

Learn more about online skimming attacks and how you can mitigate the risk of client-side data theft

Read Now

Online demo

See the Ensighten solution in action to learn how we can help protect your website against client-side attacks

Book Now