Imperva Cyber Community

JavaScript is everywhere. It’s one of the most popular programming languages for web application development.

But website developers aren’t just relying on their own code anymore. There is an enormous number of third-party web services that use JavaScript to execute code outside of their clients’ regular web security protocols.

This puts them at risk for client-side cyberattacks. Alarmingly, these attacks can be successful even with industry-standard server protection in place.

The most famous example is Magento, which fell victim to a cabal of cybercriminal organizations now called Magecart. Thousands of users rely on Magento for its e-commerce solutions, many of which run as off-site JavaScript connections.

Once hackers have compromised a JavaScript-enabled service provider, they gain immediate access to trusted connections with thousands of clients. Inserting malicious code is the next step forward from there.

Why Client-Side Attacks Are So Dangerous

The average organization’s web software stack can contain more than fifty separate JavaScript services. These automated services enable cutting-edge features like live chat, traffic analytics, payment processing, and more.

The organization itself is not processing any of this data. It sends raw data to a third-party and receives the processed data back. Hackers have begun targeting this communication channel.

JavaScript services execute inside the web browser and then make requests directly to the application. When cybercriminals figure out how to compromise this connection, it can go completely unnoticed by security professionals who typically focus on securing the application server.

Formjacking is among the most dangerous kinds of client-side attacks. If hackers compromise an e-commerce processor’s payment form, then every company using that particular payment service becomes a target. Whenever a customer enters their credit card data onto the payment form, that data is skimmed and sent to the attackers.

This attack also comes under different names. It’s also called payment skimming, digital skimming, supply-chain attacks, and JavaScript skimming.

How Hackers Do It: Compromised Repositories and S3 Buckets

If you run an e-commerce website and integrate a payment provider solution, you will probably do the same thing most engineers and developers do: Simply copy and paste the code your vendor gives you.

It’s hard for attackers to compromise code sent between vendors and clients through secure channels. But not all code is sent securely. Open source repositories like GitHub allow anyone to copy and paste code. Some vendors send their clients integration codes through unsecured email.

In these situations, it’s relatively simple for a hacker to use tried-and-true phishing methods to gain access to the code being sent. If a hacker compromises a payment processor’s email account, or finds their way into a code repository that other developers will be copying and pasting from, their changes may easily go unnoticed.

Another common tactic cybercriminals use is scanning for misconfigured Amazon S3 buckets. More than 17,000 domains have been compromised by the Magecart group using this strategy. 

If AWS users leave their S3 buckets misconfigured to allow anyone to view and edit the files they contain, cybercriminals can easily and automatically insert their code onto any JavaScript file in the bucket. Once they’ve added their malicious code to the bucket, they only need to wait for it to execute.

Since 2019, we’ve documented an active campaign to automate the process of scanning for these misconfigured buckets. Hackers do not need to manually look for vulnerabilities. Web administrators – even for very small sites – need to review their website code for suspicious artifacts and unauthorized changes.

It’s easy to see the efficiency of this approach. Cybercriminals only need to compromise a single account in order to gain access to thousands of websites. Automation essentially guarantees a financial return.

Client-Side Protection Gives Visibility Into JavaScript Connections

Before Imperva’s Client-Side Protection release, security professionals who needed to continuously monitor JavaScript connections had few options.

Performing a static code analysis of a website can uncover existing vulnerabilities and security issues, but only at the specific time when the analysis is performed.Engineers responsible for securing websites with dozens of third-party JavaScript connections cannot effectively monitor ongoing changes and updates happening to each of those services in real-time.

This turned JavaScript services into a security blind spot. Engineers and marketing employees could add new JavaScript connections to a website without interacting with security at all. Sometimes security team members would have to manually find, aggregate, and validate services in an Excel spreadsheet.

The first step to adequate protection is examination and approval. Imperva’s Client-Side Protection solution continuously monitors these connections and only allows the execution of pre-approved services.

This way, users can block connections with unapproved destinations. Even compromised code cannot send sensitive data to unknown sources from the client. 

Watch the webinar: How to protect your website from client-side attacks like Formjacking and Magecart - CSP

What About Cloud WAF Protection?

You do need Cloud WAF for Imperva’s Client-Side Protection to function. However, the two services are distinct. Cloud WAF protects your application server from bots and distributed denial of service (DDoS) attacks, but it cannot gain visibility into JavaScript executables on its own. This is because those JavaScript services are connecting on the browser and making requests that do not pass through the organization’s server.

Imperva’s Cloud WAF and Client-Side Protection services are complementary. Once you have the Cloud WAF deployed, you can then capitalize on the security benefits that Client-Side Protection offers.

Client-Side Protection Discovery and Insights

Imperva’s Client-Side Protection provides users with the ability to review changes to their trusted JavaScript connections. This gives website owners the ability to see exactly how many connections have been made, and to continuously monitor those connections through a single application.

The discovery portion of Imperva’s Client-Side Protection services give visibility into all services as they execute, eliminating the “blind spot” that most security engineers have when it comes to JavaScript connections. It allows for continuous monitoring, making it immediately obvious when new services appear, or when data is being sent to suspicious services.

Client-Side Protection uses a review system to give users granular access to JavaScript connection permissions. Upon review, users can immediately see where data is going, and whether those destinations meet security policy criteria.

For instance, you can immediately see when JavaScript executables are sending data to websites without SSL certification, or newly registered websites. You can see what resource types are being requested, and much more.

Client-side protection not only helps with the effort of aggregating JavaScript services into one location, but also collects insights about each service. This makes the process of reviewing and authorizing them much easier.