Threat by Association: Why Client-side Attack Increases Are Inevitable

Threat by Association: Why Client-side Attack Increases Are Inevitable

Ramping up Risk, pre-COVID-19 and mid-COVID-19

Enterprise organizations pour hundreds of millions into their cybersecurity initiatives, protecting  everything from remote and cloud-based resources to IoT devices to collaboration applications.

At the same time, they’re also transforming interactions with their employees and customers. They’re increasingly enabling employees to work  from home, part-time or for extended periods. And they’re beefing up their digital customer experience initiatives to make online interaction easier, more inviting, and more gratifying for their clients. They are pushing more and more enterprise IT interactions to the web browser as they migrate enterprise applications to SaaS platforms or deliver them via web front ends.

But all too often, they neglect a crucial step:  Protecting the users of websites (both customer- and employee-facing) from client-side attacks.

The Open Secret of Client-Side Attacks

This failure in large part stems from a lack of understanding of client-side attacks.

Some of this comes down to nomenclature.  A “client-side attack” sounds like something that happens to the client, like ransomware or a botnet client. Strictly speaking, client-side attacks do happen to the client, but they don’t involve installing anything on it or attacking the OS or other software. Client side attacks are instead a subversion of browser session and data security that rely on hijacking normal website functionality to use as a conduit into the browser. In  other words, the attacker uses the website to attack the clients. The client is the target, but the website is the vector.

Any website that uses  JavaScript (as the vast majority of sites do) is vulnerable. To see why, it makes sense to review what it is that JavaScript can do.

As PerimeterX R&D director Ben Diamant writes,On every web page, JavaScript code  can access, modify, create an alternative for and remove anything from the page. This includes UI elements, object prototypes, storage assets, and network activity. Large portions of website functionality are being executed via JavaScript libraries – snippets of pre-written JavaScript that make it faster and easier to do things. This is a tremendous amount of power and the risk from it is magnified by the fact that there are no easy ways for either site operators or site visitors to know when such changes have been made, and the users are at high risk if a website they are visiting has a breached library or code.

That is, access to the JavaScript that generates the page can allow the attacker to manipulate the user experience (displaying offensive images or messages), hijacking the user’s session, or just silently and transparently grab data of interest — PPI (protected personal information), security credentials, and financial data like bank account or credit card information — and send it secretly to the attacker.

In short, enterprises that fail to protect the users of their websites (whether internet-facing or internal) against client-side attacks are put both themselves and their customers at risk.

Tangled Web: Risk is Transitive

Making all this worse is the fact that it’s almost impossible to validate the security of Website code these days. Most Web applications aren’t the result of a single application, development project, or company initiative, in which the code development can be controlled end-to-end. Instead, functionality is provided–code is grabbed in from–partners, suppliers, service providers, and third-parties like advertisers. Most sites are built from a large library of plugins, for instance, and that plug-in code is provided by third parties. In short, there’s an entire “Web code supply chain” whose security can’t be validated.

Moreover, client-side attacks are often undetectable on the client as well; there are applications that evade most client-side anti-malware, even sophisticated advanced endpoint protection, since what they do looks like normal web application use.

The dynamic assembly of web application pages leaves all such sites vulnerable to client-side attacks. And the risk of such attacks is not just the risk inherent to the primary Web application itself, but the risk associated with each of the functional components provided to it dynamically, and with the companies providing them.  A compromise in any of them (and a consumer-facing site may have dozens) can lead to a client side attack. In other words, the more components that go into a website, and the more third parties it’s connected to, the higher the risk of a client-side attack.

Client-Side Attack Increases are Inevitable

Companies are increasingly moving to work from home (WFH). More than a third of companies say they will continue WFH even once we are truly post-COVID-19. Another 40% or so probably will.

What does WFH have to do with client-side attacks, you ask? Great question. A working-from-home employee could be accessing a compromised website in one tab, and logging into a corporate Web application behind the firewall on another tab. In such a scenario, the employee’s (now-compromised) client can be capturing sensitive enterprise application data–even though the server is protected behind a firewall.

In other words, two major trends are converging:
1. Companies are continuing to increase investment in web-based experiences to engage and delight clients and to support staff in their work, adding a broad range of bells and whistles (often from untested third parties) to do so.
2. Employees are increasingly working from home, further blurring the line between personal and work use of the browser and more frequently accessing corporate resources in insecure ways.

Enterprises need to think about protecting their employees and resources against these attacks, or risk the consequences!



Share this post