JavaScript web apps and web servers are susceptible to a specific type of vulnerabilities/attacks known as regular expression (regex) denial of service (ReDoS).

These vulnerabilities take place when an attacker sends large and complex pieces of text to the open input of a JavaScript-based web server or app.

If the server component or an app library is not specifically designed to handle various edge cases, the attacker’s input can end up blocking the entire app or server for seconds or minutes at a time, while the server analyzes and pattern-matches the input.

Various programming languages and web server technologies have similar issues with the performance of pattern matching operations and ReDoS attacks, but they are vastly exaggerated in the case of JavaScript because of the single-threaded execution model of most JavaScript servers, where every request is handled by the same thread.

When a ReDoS attack hits, this ends up clogging the entire server, rather than slowing down one particular operation.

ReDoS attacks known since 2012, but gaining momentum

ReDoS attacks in the case of JavaScript servers were first detailed in a research paper published in 2012, but back then, JavaScript, and Node.js, in particular, weren’t the behemoth they are today on the web development scene, hence, this particular issue went largely ignored for another half of decade.

Subsequent research published in 2017 revealed that 5% of the total vulnerabilities found in Node.js libraries and applications were ReDoS vulnerabilities.

But according to research presented at a security conference last week, the ReDoS issue is gaining momentum in the JavaScript community because it has been left unaddressed for so many years.

Cristian-Alexandru Staicu and Michael Pradel, two academics from the Technical University in Darmstadt, Germany, say they’ve found 25 previously unknown vulnerabilities in popular Node.js modules.

List of libraries vulnerable to ReDoS attacks

The two said that an attacker could craft special exploit packages and attack websites/servers using any of these 25 libraries.

Sending an exploit packages causes any of the vulnerable websites to freeze between a few seconds to even minutes, as the server is trying to match the text contained within the exploit to a regular expression (regex) pattern in order to decide what to do with the input. Such regex filters on input fields are common, as they are the base of many XSS filters.

But while one attack is bad, sending repeated exploit packages to the same server can cause prolonged downtime periods.

Nearly 340 sites vulnerable to ReDoS attacks

Staicu and Pradel say the primary reason for these flaws is the lack of attention to the performance of regex matching, as most developers seem to be focused on accuracy, leaving big holes in their code that attackers can exploit using ReDoS attacks.

The two also took their research one step further. They devised a method of detecting these vulnerabilities on live websites without actually using the ReDoS exploit code.

They used this method to scan 2,846 popular Node.js-based sites, revealing that 339 —approximately 12%— were vulnerable to at least one ReDoS vulnerabilities.

“ReDoS poses a serious threat to the availability of these sites,” the research team said. “Our results are a call-to-arms for developing techniques to detect and mitigate ReDoS vulnerabilities in JavaScript.”

Some ReDoS issues were patched

The TU Darmstadt research team reported all the vulnerabilities to the respective module developers, some of who addressed the problems. This GitHub repo contains proof-of-concept exploits for testing the vulnerable libraries but also links to the appropriate fixes for the affected modules.

Besides JavaScript, Java is also known to be affected by ReDoS attacks. In 2017, researchers from the University of Texas at Austin created a tool named Rexploiter, which they used to find 41 ReDoS vulnerabilities in 150 Java programs collected from GitHub.