Protecting Web Apps Against Client-Side JavaScript Attacks
Many security researchers believe JavaScript attacks are a major threat to web applications. The rise of Magecart, which uses web skimming (or formjacking) to illegally capture credit card and personal information from site visitors, made the threat immediate. British Airways paid a massive $229 million GDPR fine after it was ruled not to have sufficiently protected its website and mobile apps from Magecart attacks.
Multiple research reports from Symantec, F5 Networks and security researcher Graham Cluely reported massive ongoing JavaScript attacks exploiting weaknesses in modern web apps. It has gotten so bad that the PCI Security Council took the rare step of warning e-commerce operators about the threat. The reason for this is clear: The rise of third-party code libraries and services, which are included as JavaScript code in web apps, have expanded the attack surface for hard-to-detect JavaScript attacks. (I covered this in a previous post).
Those third-party libraries and services today comprise more than 70% of web apps’ code and functionality. Usually, an attacker will either compromise the third-party’s code or the actual web application code and insert modified code that will, for example, sniff credit card information and send it to another server somewhere else via an encrypted connection. These types of stealthy attacks are difficult to spot because they don’t obviously impact web application performance, are invisible to users and happy outside the site operator’s perimeter.
How can site reliability or security teams protect their web apps? There are three primary approaches to better securing JavaScript code. In this article, we’ll look at them and analyze their strengths and weaknesses.
Approach 1: Static Code Analysis
Shortened as SCA and also known as static application security testing (SAST), this method is usually performed as part of a code review. Developers and DevOps teams usually undertake this by running web application code through various SCA tools tuned to highlight possible vulnerabilities in static (non-running) source code. SCA tools do this using various common techniques including data-flow analysis, taint analysis and lexical analysis, among others. SCA looks for a variety of known code flaws such as unbuffered form fields or other ways to overwhelm user input mechanisms and override business logic.
Ideally, SCA would spot all application security flaws. In reality, modern web apps are too complicated for SCA to be definitive; advanced malicious code can bypass some of the detection mechanisms by obfuscating vulnerabilities. Additionally, SCA is useless in spotting compromised code in third-party services that are included as JavaScript components on a site that are loaded from the third party’s host. SCA can be pointed at third-party libraries that are open source, but this requires a separate operation. Further, the static code analysis covers only a single point in time, while third-party code in most cases is updated very frequently. What’s more, third-party code may incorporate fourth-party code (and by extension fifth-party and so on), creating a Russian nesting doll effect. This complicates SCA even further. SCA is still very useful and can help developers release better code, but it’s only a first line of defense and as stated above, can’t cover third-party code or detect some of the more complex vulnerabilities.
Approach 2: Dynamic Application Security Testing (DAST)
Application security testing is a method using automated tools to scan web apps from the outside in as a “black box,” analyzing the application and looking for well-known vulnerabilities such as cross-site scripting, SQL injection, or command injection. There are dozens of scanning tools available, including several really good open source products. Effective passive scanning tools can identify well-understood problems in live code that is running in a web application. More sophisticated scanners also can analyze code as it is running (in runtime), making it more difficult for malicious hackers to hide attacks.
Passive scanning tools have crucial weaknesses. Advanced attackers will identify scanners by mapping their IP addresses or detecting the automated clients running the test. These attackers will serve a benign code to scanners and requests that could be coming from the site owner, and will serve the vulnerable code only to verified targeted users (e.g. cryptowallet holders).
Approach 3: Real-User Runtime Analysis
These systems examine code from the inside out, looking for live behaviors that are irregular. Runtime analysis can be used to study how a web application interacts with a user—how it presents information and how it reacts to conditional patterns. Because it can see exactly what an application is doing with every bit of information running through the application and all data provided by users, runtime analysis can identify anomalous behaviors originating from third-party JavaScript libraries and services and can trace anomalous behavior that may instantiate only in specific use cases (being it a bug that a developer introduced or a sophisticated malware crafted by an attacker). This way runtime analyzers can see things that are “strange,” such as an extra field added to a form by malicious hackers trying to grab bank information from unsuspecting site visitors or a script that hijacks payment information typed in by a user and sends it to some new, unknown site. Because this runtime code is running on real users as part of the application, it gives the best visibility to what’s happening on the client-side, on all users, avoiding the pitfalls of AST scanners.
Which Approach Should You Use?
All three approaches are useful and play a key role in security. SCA is an excellent method for improving security during pre-deployment. DAST serves as a primary layer of defense to spot obvious problems and covers some runtime problems, but can’t be relied on to stop the most sophisticated attacks. Real-user runtime analysis is the second layer, the “eye-in-the-sky” that detects more sophisticated attacks and anomalies and directs security teams to these hotspots. A smart strategy to protect web apps against JavaScript attacks will use all three in conjunction, creating overlapping layers of security.
