DAPP: automatic detection and analysis of prototype pollution vulnerability in Node.js modules

Abstract

The safe maintenance of Node.js modules is critical in the software security industry. Most server-side web applications are built on Node.js, an environment that is highly dependent on modules. However, there is clear lack of research on Node.js module security. This study focuses particularly on prototype pollution vulnerability, which is an emerging security vulnerability type that has also not been studied widely. To this point, the main goal of this paper is to propose patterns that can identify prototype pollution vulnerabilities. We developed an automatic static analysis tool called DAPP, which targets all the real-world modules registered in the Node Package Manager. DAPP can discover the proposed patterns in each Node.js module in a matter of a few seconds, and it mainly performs and integrates a static analysis based on abstract syntax tree and control flow graph. This study suggests an improved and efficient analysis methodology. We conducted multiple empirical tests to evaluate and compare our state-of-the-art methodology with previous analysis tools, and we found that our tool is exhaustive and works well with modern JavaScript syntax. To this end, our research demonstrates how DAPP found over 37 previously undiscovered prototype pollution vulnerabilities among 30,000 of the most downloaded Node.js modules. To evaluate DAPP, we expanded the experiment and ran our tool on 100,000 Node.js modules. The evaluation results show a high level of performance for DAPP along with the root causes for false positives and false negatives. Finally, we reported the 37 vulnerabilities, respectively, and obtained 24 CVE IDs mostly with 9.8 CVSS scores.

Appendix A: Mitigations for prototype pollution vulnerability

After we reported those 37 vulnerabilities through NPM, some of the modules are newly patched to avoid prototype pollution attack. This process helped us to organize how to mitigate prototype pollution attack with today techniques. This section summarizes how to mitigate prototype pollution vulnerability.

1.1 Appendix A.1: Use Object.hasOwnProperty

The “Object.hasOwnProperty” method can be used to check the existence of certain properties of the target object. Thus, even if the value of a key such as “constructor” is specified, the reference can be prevented. In this way, unlike the “in” operator which works similar to the “Object.hasOwnProperty” method, the developer can prevent the prototype references. The difference between “Object.hasOwnProperty” and “in” operator is shown in Listing 21.

Algorithm 4 shows how to mitigate prototype pollution by using “Object.hasOwnProperty” function. However, this method is not available for the new property settings that did not exist originally.

1.2 Appendix A.2: Make “__proto__” empty

Typically, to initialize object in JavaScript, it is usually initialized in the following ways.

However, when initializing this way, the “__proto__” property of the “obj” in Listing 22 will refer to the prototype of the constructor Object. If the attacker contaminates the “__proto__” property of “obj,” the “Object.prototype” is also contaminated. Since the global object also inherits the “Object.prototype,” other contexts will refer to the contaminated property which can generate prototype pollution vulnerability.

The fundamental problem here is that “__proto__” of the object literal refers to the “Object.prototype,” so contaminating the “__proto__” will also pollutes other objects. Therefore, by making “__proto__” empty, the developer can delete the reference of the “Object.prototype.” Listing 23 and Listing 24 show how to initialize “__proto__” to null.

1.3 Appendix A.3: Filtering by Keyname

This method prevents prototype pollution vulnerability by filtering the values of key with certain names such as “prototype,” “__proto__,” and “constructor.”

Algorithm 5 shows how to mitigate prototype pollution by setting a keyword filter. Most of patched modules take this approach. Creating a mitigation with keyword filters can help prevent pollution without being limited to the execution environment.

Listing 25 is a code actually used to prevent prototype pollution of the “dot-prop” module. We have reported the vulnerability on Oct 14, 2019, and the patched source code was committed on Oct 23, 2019. The vendor added a function that checks disallowed keys while splitting object name with dot notation.

1.4 Appendix A.4: Prototype freezing

“Object.freeze” is a JavaScript native function that makes objects read-only. By applying this function to the object “Object.prototype,” the properties of the “Object.prototype” will become unchangeable as shown in Listing 26.

However, this method can cause serious errors when using libraries that require modification of the object prototypes. Therefore, this may not be applicable in all situations.