Is Neglecting the Client Side Costing Your Business?

"Companies of all shapes and sizes rely on a webpage that anchors them to the online world.

Webpages represent the face of the majority of businesses and provide a first glimpse for many potential customers. With this in mind, organizations have specific security requirements and the need to make sure that their web platforms or online presence is secure.

We should highlight those who do business in sectors where the cost of fraud can be significant and the loss of reputation dramatic, ie banking and financial services, e-commerce, or government.

The web browser

The web browser is permissive. Both JavaScript and a web page's DOM are highly dynamic and modifiable during runtime. Anything that has unrestricted access to the execution context of the webpage is able to modify both the code and the web page DOM. But why would an attacker want to do that in the first place?

The main motivations behind tampering with a webpage and its code can include:

• Credentials harvesting

• Interfering with financial transactions or stealing money

• Personal Identifiable Information (PII) and Personal Health Information (PHI) leakage

• To present malicious content to deceive and manipulate the user

• To perform actions which impersonate the user of the website

Of course, having unrestricted access to the execution context is no small thing. If this were the case, all web pages would be doomed. So, how can attackers attain this capability?

The obvious, and traditional way, is to find and exploit an injection vulnerability that allows the attacker to run its own code on the webpage.

Over the last few years, there has been a huge focus on addressing web application vulnerabilities, not only to prevent infrastructure from being compromised and assets stolen, but also to make users safe.

It would be fair to say that the AppSec community has been reasonably successful in this mission. That is not to say that web applications don't have vulnerabilities, but they are way more complex now and much more difficult to find.

Security awareness, good documentation, and tools such as static analyzers, scanners, or fuzzers have all played an important part in this success.

However, this success has made attackers more determined and they have adapted their approach accordingly to include factors other than just web application vulnerabilities. There are two attack avenues that they can follow:

1. Target the end user and its device by infecting the devices with a Man-in-the-Browser (MITB) Trojan or by deploying malicious browser extensions that the users inadvertently install,

2. Target third-party code and dependencies that the web application is using.

Man-in-the-Middle (MITM), and Man-in-the-Browser (MITB) attacks

Malicious browser extensions are quite effective in modifying the way users interact with applications and capturing or tampering with the data that flows through them.

Some of these devices can be owned by users of these websites and the experience they get may not be the one that the server delivers.

These damaging consequences are a result of a continuing cycle where the user's machines keep getting infected, an almost certainty for a percentage of your users, and because these types of malware are able to inject code into the client-side without being noticed, solutions to detect these injections and mitigate them are needed.

In 2014, Kapravelos et al, found that five percent of 48,000 extensions from the Chrome webstore were injecting dynamic JavaScript into the webpage.

A few extensions were doing nasty things such as preventing extension uninstall, stealing passwords from forms, keylogging, injecting security-related HTTP headers, and connecting to arbitrary servers. According to recent research, MITB capabilities are at the top of the wish list for cyber-criminals today.

Nowadays, web development relies on third parties more than ever before. The evidence is clear; third-party code is all over web applications, both on the server side and the client-side. Some code is even loaded at runtime from remote servers, which pretty much takes them out of the web developer's control, whilst still giving them the capability to completely change the application in runtime.

It's easy to anticipate that this has the hallmark for everything to go wrong. In late 2014, jQuery CDN was hacked and for a short period was planting the RIG exploit kit into vulnerable visitors of websites using jQuery from its CDN.

For attackers, this is an even better way of delivering malware, and we will see more and more of this moving forward. In the face of these challenges, new standard proposals such as Subresources Integrity (SRI) and Content Security Policy (CSP) have been put forward. However, these alone are not enough to mitigate third-party code carrying malicious payloads that target applications.

Allaying the dangers and creating awareness about web application threats that do not rely on web application vulnerabilities should rightly motivate further discussion within the AppSec community and beyond.

Conclusion

Any organization with an important online presence or that deals with sensitive data should be able to get precise information on what code was injected and where giving them visibility on what's happening with their applications on the client-side and helping prevent a class of attack that is growing in frequency and complexity."

Contributed by Pedro Fortuna, co-founder and CTO, of Jscrambler.
Originally published in SC Magazine UK on July 18, 2017.