The Blindspot of Web Security is Client-side Code
One of the troubling blindspots for security teams is third party JavaScript services embedded on a website. The popularity of JavaScript services used by developers and marketing teams means this blindspot is hiding an expanding attack service. If a web developer installs a live chat function, traffic analytics, marketing automation, or a payment processor, it is typically deployed using a small JavaScript snippet from a third party. This JavaScript executes on the client and sends data to wherever that code defines. It’s not unusual for companies to have over fifty JavaScript services on their site and many of these constantly communicate data to the approved third parties–and it is this communication that is under attack.
Why is Client-side Code a Problem?
Protecting the application server is the fundamental principle behind many security solutions including Web Application Firewalls, DDoS, and Bot Protection. Security teams are very familiar with protecting against such attacks on the server. But these JavaScript services execute on the client side, inside the browser, and the communication travels directly to the third-party. The security team and the user don’t typically see this communication happening. If this third party code becomes compromised, and is poisoned to send data to somewhere other than the approved service, this communication stream is a real-time data breach missed by traditional security tools.
What is a Client-side Attack?
Why is the company blind to this attack? Mainly because the website is not directly targeted by an attacker. Instead it is the 3rd party code that has been poisoned. It could have been injected with malicious code on a github repository, and wherever that code is subsequently deployed is the victim of the client-side attack. In the well known Magecart attacks, the code of a third party payment processor was compromised and any company that used the same version on their website was a victim. The payment form was formjacked, and if a user submitted their payment card details, a copy of that data was skimmed and sent to the Magecart attackers. Gaining visibility into the destination of any communication by all JavaScript services on a website is a significant improvement for any security team struggling with or fearing client-side attacks.
Static Analysis or Dynamic Discovery of JavaScript Services?
A static code analysis of the website uncovers vulnerabilities and security issues at a single point in time. But what happens to the ongoing changes or upgrades in JavaScript services that happen over time? Having the ability to explicitly approve services is the first step to protection. But only continuously monitoring catches any new unapproved services that were added by a third party and are attempting to execute.
Client-Side Protection
By adopting Imperva’s Client-Side Protection, enterprises prevent data theft from client-side attacks like formjacking, digital skimming, and Magecart. The solution gives security teams visibility and control over any third party JavaScript code embedded in its web applications and continuously monitors which JavaScript services are present and only allows pre-approved services to execute. By offering this view into third party JavaScript services deployed by development teams, Imperva is placing power in the hands of the security team to protect their website.
Try Imperva for Free
Protect your business for 30 days on Imperva.
