Client-Side Security and the Fight Against Magecart Attacks
Page Shield, Cloudflare's client-side security product, is now generally available. It is designed to protect website end users from client-side attacks that exploit vulnerable JavaScript dependencies to execute malicious code in the browser. A primary concern is the exfiltration of sensitive user data to attacker-controlled domains, commonly known as Magecart-style attacks. These incidents have previously affected major organizations, leading to significant penalties under GDPR.
Anatomy of a Client-Side Attack
A Magecart-style attack follows a straightforward two-stage process. First, the attacker compromises a JavaScript file that is running on the target website. Second, they inject malicious code designed to read personally identifiable information (PII) entered by users and send it to a domain they control. High-value targets include online retailers with credit card checkout forms, online banking portals, login pages, and any form requesting personal data.
Attackers have several vectors for compromising a legitimate library and deploying their code:
- Compromising third-party providers
- Compromising the website directly
- Exploiting vulnerabilities
In many cases, the third-party provider itself is breached, giving the attacker the ability to alter code distributed to many sites, as occurred with the Ibenta breach affecting Ticketmaster. Alternatively, an attacker with admin access to the site can directly modify a script, which was the method used against British Airways in 2018. Also, libraries that are end-of-life and unmaintained become vulnerable to zero-day exploits, enabling automated attacks to compromise thousands of checkout pages at once.
Core Defense Mechanisms
Various defense mechanisms are available to application security teams to counter these threats:
- Content Security Policies: Using a CSP with a report-only directive, browsers can send information to Page Shield about the scripts executing on an application, offering basic visibility to site owners.
- Static Analysis: Automated analysis of downloaded scripts, utilizing machine learning or signature databases, can flag malicious content that might otherwise go unnoticed.
- Threat Feeds: Databases of known malicious hostnames and URLs are effective for identifying recognized malware and complement tools designed for novel attacks.
- Subresource Integrity Checks: Site owners can add a cryptographic hash in the
integrityattribute of a script or link to protect against unauthorized alterations by malicious parties. - External Connection Checks: Extracting and comparing a script's external connections against blocklists and allowlists helps spot attempts to exfiltrate data to attacker-controlled domains.
Page Shield currently employs CSP reports, threat-intelligence feeds, and ML-based static analysis. Static analysis, with its ability to uncover attacks that other mechanisms might miss, is considered a crucial element in detecting client-side threats.
Static Analysis: A Two-Track Approach
The static analysis system is designed to handle two distinct scenarios:
- The code is readable and its functionality is not obscured.
- The code's functionality is obscured, whether intentionally or not.
This results in four categories of scripts: benign, malicious, obfuscated/minified benign, and obfuscated malicious. Separate models are used for each scenario. One model detects malicious scripts where the code is clean. The other focuses on obfuscated scripts, distinguishing between malicious and benign content.
Analyzing Clean Scripts with Data Flow
Detection of unobscured malicious scripts relies on data flow properties derived from an abstract syntax tree (AST), a graph-based representation of the program's structure. The AST is used to flag significant structural changes and to build a data flow graph that tracks data movement between variable assignments and function calls.
An ML model identifies nodes on this graph related to PII reads or malicious data exfiltration. A script is classified as malicious if there is a connected path on the graph linking nodes for PII reads to those responsible for the exfiltration call to an attacker-controlled domain. This data-flow approach, which requires the connection to be demonstrated, is effective and minimizes false positives that tend to arise from models that don't verify the link between disconnected logic.
Handling Obfuscation: Revealed Risk and Beyond
Attackers often try to evade detection by encoding and transforming their code. A separate model handles this type of content. For instance, an attack might use hex-encoded strings stored in a list that is referenced later in the script. Normalizing this content by decoding hex substrings reveals common JavaScript keywords used in the attack.
The core concept here is "revealed-risk" — how risky the content is once decoded, which differentiates between obfuscated malware and legitimate uses of minification or character encoding. The presence of certain keywords after normalization provides a strong signal of an attack.
However, normalization is not always straightforward. Attackers frequently use custom-defined obfuscation functions that apply an arbitrary series of transformations to a string, a method that resists simple decoding. In these cases, normalizing the string can require executing the code. To prevent this as a trivial bypass, the model also flags the presence of malicious-looking, encoded strings that cannot be normalized.
Future Development
Page Shield's detection capabilities are currently able to identify most attacks observed to date by analyzing clean and obfuscated content separately, searching for connected paths on the data flow graph, and evaluating revealed risk or arbitrary string transformations. The detection is subject to ongoing improvement, with content-based risk scoring expected to expand to other attack types, such as crypto-mining and adware. Page Shield's enterprise add-on, which includes content-based detection of Magecart-style attacks, is available for Enterprise customers.
