The Client-Side Battle Against JavaScript Attacks Is Already Here

In our previous blog post we discussed how client-side code — code residing in a web application — has become the largest part of a web app, and a popular method for developers to use when they introduce new capabilities into web applications. We touched on how unauthorized modification of client-side code has become a popular method for changing the content or altering the behavior of websites through malicious attacks. We also covered why website operators have no visibility into what happens inside their users’ browsers when their client-side code is changed. We explained briefly how JavaScript code that runs on a website may actually be generated elsewhere in a JavaScript library that is controlled by a third-party vendor or open-source maintainer. And we looked at how these unauthorized changes to otherwise respected and trusted JavaScript libraries run on the client side, through injection of malicious code, are an increasingly popular attack method against e-commerce, travel and finance company web applications.

In this post, we’ll go deeper into the problem. More specifically, we will review how changes to JavaScript libraries made in client-side attacks can alter website behavior without site visitors noticing. We will explore how these types of behaviors can harm end users. These damages include manipulating the user experience, hijacking the user’s session and leaking or stealing user data such as sensitive personal information, account passwords, and financial data like bank account or credit card account numbers. Additionally, this post will also review some of the known recent client-side attacks on JavaScript libraries. We will conclude by covering common approaches to face these threats, what the problems with those approaches might be, and recommend best practices to deal with these threats.

JavaScript Methods Used by Bad Actors

Before running through real-life threats and examples, let’s review the power (Read more...)