“Companies of all shapes and sizes rely on a webpage that anchors them to the online world.
Webpages represent the face of most businesses and offer a first glimpse to many potential customers. With this in mind, organizations have specific security requirements and must ensure their web platforms and online presence are secure.
We should highlight those who do business in sectors where the cost of fraud can be high and reputational loss dramatic, i.e., 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 with unrestricted access to the webpage’s execution context can modify both the code and the web page DOM. But why would an attacker want to do that?
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 that impersonate the user of the website
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, traditional way is to find and exploit an injection vulnerability that lets an attacker run their 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 compromise and asset theft, but also to protect users.
It’s fair to say the AppSec community has been reasonably successful in this mission. That is not to say web applications don’t have vulnerabilities, but they are far more complex now and much harder 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 to include factors beyond web application vulnerabilities. There are two attack avenues that they can follow:
- Target the end user and their device by infecting the device with a Man-in-the-Browser (MITB) Trojan or by deploying malicious browser extensions that the users inadvertently install,
- 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 can effectively modify how users interact with applications and capture or tamper with the data that flows through them.
Some of these devices can be owned by website users, and the experience they get may not match what the server delivers.
These damaging consequences result from a continuing cycle in which users’ machines keep getting infected, an almost certainty for a percentage of users, and because this malware can inject code into the client side without being noticed, solutions to detect and mitigate these injections 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 did nasty things such as preventing uninstallation, stealing passwords from forms, keylogging, injecting security-related HTTP headers, and connecting to arbitrary servers. Recent research shows MITB capabilities are at the top of cybercriminals’ wish lists today.
Today, web development relies on third parties more than ever. The evidence is clear: third-party code is everywhere in 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 it out of the web developer’s control, whilst still giving them the capability to completely change the application at runtime.
It’s easy to see this as a sign that everything is going wrong. In late 2014, attackers hacked the jQuery CDN and, for a short period, planted the RIG exploit kit on vulnerable visitors of websites using jQuery from the CDN.
For attackers, this is an even better way to deliver malware, and we will see more of this moving forward. In response, new standards such as Subresource Integrity (SRI) and Content Security Policy (CSP) have been proposed. However, these alone are not enough to mitigate third-party code that carries malicious payloads targeting applications.
Addressing these dangers and raising awareness of web application threats that don’t 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.
