Never Trust Your Application’s Supply Chain with Security
To understand why the application supply chain is an area that should not be overlooked, we must first understand the current cyber threat landscape and how modern applications are built.
Until not too long ago — just a matter of a few years — most applications were built with 3-Tier architecture or a monolithic structure. They were usually hosted in a local data center where most of the content was provided by the web server. The application perimeter was easy to define and protect — a single entry point protected by a traditional on-prem ADC (Application Delivery Controller) and a WAF (Web Application Firewalls).
Nowadays applications are hosted in multiple environments — on-premise and in the cloud — and rely on many API connections to internal and external services, and dozens of different third-party JavaScript services (ads, stock management, payment services, JS services like Outbrain, Google Analytics, Tranzila, WordPress, Magento, social media embedded widgets and content, etc.). Some of these JavaScript services are even dependent on their own fourth- and fifth-party JS services, which can be considered their own supply chain. And a substantial portion of the content your application is presenting to its end-users is now composed by the web browser.
Now Let Us Talk About the Attackers
The threat landscape has also evolved and local on-prem WAF is no longer enough to protect the application’s data. We see organizations use multiple WAFs for their different environments, as well as DDoS protection solutions and bot management tools. WAF, DDoS, bot and API protection tools have become the go-to for protecting the application’s main digital assets and data centers. And as server-side security improves, more and more hackers seek new ways of achieving their nefarious goals by abusing overlooked third-party services and connections in your applications infrastructure. It is here that they launch attacks through the less protected and monitored client-side supply chain.
One of the ways in which hackers now seek to exploit vulnerabilities in the application supply chain is formjacking, also known as Magecart and skimming. It is a clandestine attack methodology in which sophisticated attackers hide malicious malware in one of the application’s third-party services. So, once a user gets an HTML response from the app to initiate a form request to the infected third-party service, now — in response — a malicious code is injected directly onto the target’s form. It then collects the sensitive info the end-user enters and sends it back to the attacker’s remote server.
What Can Your WAF Do About It?
While you do your best to protect your application environments and customers’ personal data, the information your end-users enter on their browser side (e.g., ID numbers, addresses, credit card numbers, contact info, etc.) can be exposed to third-party services embedded in your application. These are automatically trusted by the main application but are rarely monitored. From a compliance standpoint — and as far as regulators are concerned — you are liable for any data breach or leakage of your end-users’ information on the browser side of your application just like on your server side (data center). In simple terms, your end users visit and trust your website; they do not care which third-party services you rely on.
Visibility And Control Over the Unmonitored Data Path
Traditional WAFs are designed to monitor only the incoming traffic to your applications — the data path between end users and the application. Since they are deployed as an on-prem appliance or as a reverse proxy cloud WAF, they are blind to any communication between the end-user browser and the application’s third-party services. As far as regulators are concerned, organizations are responsible for the safety of their end-users’ data and PII (personally identifiable information). It is imperative that customers’ privacy is not jeopardized by any third-party services incorporated into their apps. But there is a problem — a few important things are simply out of your control. For instance:
- You have no way of knowing if the JS code of services in the supply chain has been breached or tampered with;
- You have no control of third-party services’ security; and
- You have no way of monitoring the supply chain (sub-services from 4th party, 5th party, etc.).
Therefore, a client-side protection tool is necessary for protecting your users’ data and accounts and adhering to compliance regulations. At the end of the day, it is your application that made end-users connect with those third-party apps.
What To Look For in a Client-side Protection Solution
Visibility — in many organizations, the person in charge of securing the app is not necessarily aware of all the different third-party services and platforms that are in use. So, the first thing to look for in a client-side protection tool is its ability to automatically map and expose all third-party services in your supply chain.
Detection — Client-side protection needs to continuously detect and alert you of any changes in your supply chain. This includes any unusual communications or illegitimate script parameters between your end-users’ browsers and your application’s third-party services.
WAF integrated solution — Your client-side protection tool should be a seamless part of your WAF, so it can mitigate and block anomalous and nefarious requests and prevent data leakage.
Granular mitigation — Last, but not least, because most of the third-party JS services in your supply chain are vital to your application functionality, it is important to use a client-side protection solution that provides the option to surgically block only the nefarious scripts and not take entire services down.
For More Information about Client-Side Protection
For more information about Radware’s Client-Side Protection Solution, contact the talented, tenured cybersecurity professionals at Radware. They have been keeping customers’ networks and data secure for 25 years. They would love to hear from you.
