Client-Side Attacks: What They Are and How to Prevent Them | CHEQ

--------------------------------

The biggest risk of a client-side attack is a major data breach. In 2022, the average total cost of a data breach, including fines and recovery costs, tops $4.35 million. And in highly regulated industries like healthcare and financial services, the cost can be much higher.

Security is not a static business. Hackers innovate and continuously move to exploit the point of least resistance, and increasingly, the path of least resistance is client-side application or browser based attacks. In this article, we’ll outline how client-side security vulnerabilities can leave organizations open to attack, and a few tools and best practices businesses can leverage to defend themselves.

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.

11.3% of inbound traffic is fake or fraudulent. Download our Free State of Fake Traffic 2023 report to learn more.

JavaScript: powerful but risky

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 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.

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

Web Skimming/Formjacking

Hackers use web skimming attacks to steal user data by injecting malware into a web page, often via a compromised third-party script, which will then target sources of personal data such as cookies, general page data, or HTML forms.

Online skimming attacks can be difficult to detect due to limited visibility into third party JavaScript libraries, but it’s important to note that data processors are liable for skimming attacks on their websites, regardless of the origin of the vulnerability. Learn more about web skimming and shopping cart attacks in our recent blog. 

Cross-Site Scripting

Cross-site scripting (XSS) attacks are widely used web application attacks. XSS attacks are a form of injection attack in which attackers insert malicious script–often JavaScript–into a trusted website or application, which will then carry that malicious code onto the user’s browser, giving the attacker the ability to observe user behavior, access cookies, load fake or external content, and steal sensitive data. Learn how XSS attacks work.

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.

CHEQ’s Go-to-Market Security platform enables organizations to implement a client-side data protection and privacy enforcement approach.

Latest Posts

Ready to secure your
Go-to-Market efforts?

Get started