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.

This is a preview of subscription content, access via your institution.

Fig. 1
Fig. 2
Fig. 3
Fig. 4

Availability of data and material

The data and material that support the findings of this study are available from the corresponding author, Kyounggon Kim, upon reasonable request.

Code availability The data and material that support the findings of this study are available from the corresponding author, Kyounggon Kim, upon reasonable request.

References

  1. 1.

    Acorn.: acorn (2019). https://www.npmjs.com/package/acorn. Online; Accessed 10 Dec 2019

  2. 2.

    Arteau, O.: Holyvier/prototype-pollution-nsec18 (2018). https://github.com/HoLyVieR/prototype-pollution-nsec18. Online; Accessed 10 Aug 2020

  3. 3.

    Babel-eslint.: babel-eslint (2019). https://www.npmjs.com/package/babel-eslint. Online; Accessed 10 Dec 2019

  4. 4.

    Christensen, H.K., Brodal, G.S.: Algorithms for finding dominators in directed graphs. PhD thesis, Aarhus Universitet, Datalogisk Institut (2016)

  5. 5.

    Davis, J., Thekumparampil, A., Lee, D.: Node. fz: fuzzing the server-side event-driven architecture. In: Proceedings of the Twelfth European Conference on Computer Systems, pp. 145–160. ACM (2017)

  6. 6.

    De Groef, W., Massacci, F., Piessens, F.: Nodesentry: least-privilege library integration for server-side Javascript. In: Proceedings of the 30th Annual Computer Security Applications Conference, pp. 446–455. ACM (2014)

  7. 7.

    Duračík, M., Kršák, E., Hrkút, P.: Current trends in source code analysis, plagiarism detection and issues of analysis big datasets. Procedia Eng. 192, 136–141 (2017)

  8. 8.

    Esgraph.: esgraph (2019). https://www.npmjs.com/package/esgraph. Online; Accessed 10 Dec 2019

  9. 9.

    Gauthier, F., Hassanshahi, B., Jordan, A.: A ffogato: runtime detection of injection attacks for node.js. In: Companion Proceedings for the ISSTA/ECOOP 2018 Workshops, pp. 94–99. ACM (2018)

  10. 10.

    Georgiadis, L., Tarjan, R.E., Werneck, R.F.: Finding dominators in practice. J. Graph Algorithms Appl. 10(1), 69–94 (2006)

    MathSciNet  Article  Google Scholar 

  11. 11.

    Ghaffarian, S.M., Shahriari, H.R.: Software vulnerability analysis and discovery using machine-learning and data-mining techniques: a survey. ACM Comput. Surv.: CSUR 50(4), 56 (2017)

    Article  Google Scholar 

  12. 12.

    Gong, L., Pradel, M., Sridharan, M., Sen, K.: Dlint: dynamically checking bad coding practices in javascript. In: Proceedings of the 2015 International Symposium on Software Testing and Analysis, pp. 94–105. ACM (2015)

  13. 13.

    Grieco, G., Grinblat, G.L., Uzal, L., Rawat, S., Feist, J., Mounier, L.: Toward large-scale vulnerability discovery using machine learning. In: Proceedings of the Sixth ACM Conference on Data and Application Security and Privacy, pp. 85–96. ACM (2016)

  14. 14.

    Gupta, R.: Generalized dominators and post-dominators. In: Proceedings of the 19th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pp. 246–257. ACM (1992)

  15. 15.

    Hidayat, A. esprima (2018). https://www.npmjs.com/package/esprima, https://esprima.org/. Online; Accessed 10 Dec 2019

  16. 16.

    Holland, B., Santhanam, G.R., Awadhutkar, P., Kothari, S.: Statically-informed dynamic analysis tools to detect algorithmic complexity vulnerabilities. In: 2016 IEEE 16th International Working Conference on Source Code Analysis and Manipulation (SCAM), pp. 79–84. IEEE (2016)

  17. 17.

    Jovanovic, N., Kruegel, C., Kirda, E.: Pixy: a static analysis tool for detecting web application vulnerabilities. In: 2006 IEEE Symposium on Security and Privacy (S&P’06), pp. 6–pp. IEEE (2006)

  18. 18.

    Lengauer, T., Tarjan, R.E.: A fast algorithm for finding dominators in a flowgraph. ACM Trans. Program. Lang. Syst.: TOPLAS 1(1), 121–141 (1979)

    Article  Google Scholar 

  19. 19.

    Madsen, M., Tip, F., Lhoták, O.: Static analysis of event-driven node.js Javascript applications. In: ACM SIGPLAN Notices, vol. 50, pp. 505–519. ACM (2015)

  20. 20.

    Murthy, P.K.: Constructing a control flow graph for a software program, February 3 (2015). US Patent 8,949,811

  21. 21.

    nodejs.: nodejs (2019). https://nodejs.org/en/about/. Online; Accessed 10 Dec 2019

  22. 22.

    Ojamaa, A., Düüna, K.: Assessing the security of node.js platform. In: 2012 International Conference for Internet Technology and Secured Transactions, pp. 348–355. IEEE (2012)

  23. 23.

    OWASP: Owasp dependency check (2019). https://www.owasp.org/index.php/OWASP_Dependency_Check. Online; Accessed 10 Dec 2019

  24. 24.

    Patel, P.R.: Existence of Dependency-Based Attacks in NodeJS Environment. In: Creative Components. 91 (2018). https://lib.dr.iastate.edu/creativecomponents/91. Accessed 10 Dec 2019

  25. 25.

    Patnaik, N., Sahoo, S.: Javascript static security analysis made easy with jsprime. Blackhat USA (2013)

  26. 26.

    Pfretzschner, B., ben Othmane, L.: Identification of dependency-based attacks on node.js. In: Proceedings of the 12th International Conference on Availability, Reliability and Security, p. 68. ACM (2017)

  27. 27.

    Quinlan, D.J., Vuduc, R.W., Misherghi, G.: Techniques for specifying bug patterns. In: Proceedings of the 2007 ACM Workshop on Parallel and Distributed Systems: Testing and Debugging, pp. 27–35. ACM (2007)

  28. 28.

    Retire.js.: Retire.js (2019). https://retirejs.github.io/retire.js/. Online; Accessed 10 Dec 2019

  29. 29.

    Scandariato, R., Walden, J., Hovsepyan, A., Joosen, W.: Predicting vulnerable software components via text mining. IEEE Trans. Softw. Eng. 40(10), 993–1006 (2014)

    Article  Google Scholar 

  30. 30.

    Sen, K., Kalasapur, S., Brutch, T., Gibbs, S.: Jalangi: a selective record-replay and dynamic analysis framework for Javascript. In: Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, pp. 488–498. ACM (2013)

  31. 31.

    Sharir, M.: A strong-connectivity algorithm and its applications in data flow analysis. Comput. Math. Appl. 7(1), 67–72 (1981)

    MathSciNet  Article  Google Scholar 

  32. 32.

    Snyk: Prototype pollution (2019a). https://snyk.io/vuln/SNYK-JS-JQUERY-174006. Online; Accessed 10 Dec 2019

  33. 33.

    Snyk: Snyk (2019b). https://github.com/snyk/snyk. Online; Accessed 10 Dec 2019

  34. 34.

    SourceClear: Sourceclear (2019). https://www.sourceclear.com/. Online; Accessed 10 Dec 2019

  35. 35.

    Staicu, C.-A., Pradel, M., Livshits, B.: Understanding and automatically preventing injection attacks on node.js. Technical report, Technical Report TUD-CS-2016-14663, TU Darmstadt, Department of Computer Science (2016)

  36. 36.

    Sun, H., Bonetta, D., Humer, C., Binder, W.: Efficient dynamic analysis for node.js. In: Proceedings of the 27th International Conference on Compiler Construction, pp. 196–206. ACM (2018)

  37. 37.

    Tao, G., Guowei, D., Hu, Q., Baojiang, C.: Improved plagiarism detection algorithm based on abstract syntax tree. In: 2013 Fourth International Conference on Emerging Intelligent Data and Web Technologies, pp. 714–719. IEEE (2013)

  38. 38.

    Xie, Y., Aiken, A.: Static detection of security vulnerabilities in scripting languages. In: USENIX Security Symposium, vol. 15, pp. 179–192 (2006)

  39. 39.

    Yamaguchi, F., Lindner, F., Rieck, K.: Vulnerability extrapolation: assisted discovery of vulnerabilities using machine learning. In: Proceedings of the 5th USENIX Conference on Offensive Technologies, pp. 13. USENIX Association (2011)

  40. 40.

    Yamaguchi, F., Lottmann, M., Rieck, K.: Generalized vulnerability extrapolation using abstract syntax trees. In: Proceedings of the 28th Annual Computer Security Applications Conference, pp. 359–368. ACM (2012)

  41. 41.

    Yamaguchi, F., Golde, N., Arp, D., Rieck, K.: Modeling and discovering vulnerabilities with code property graphs. In: 2014 IEEE Symposium on Security and Privacy, pp. 590–604. IEEE (2014)

  42. 42.

    Zhao, J., Xia, K., Fu, Y., Cui, B.: An ast-based code plagiarism detection algorithm. In: 2015 10th International Conference on Broadband and Wireless Computing, Communication and Applications (BWCCA), pp. 178–182. IEEE (2015)

  43. 43.

    Zheng, M., Pan, X., Lillis, D.: Codex: source code plagiarism detection based on abstract syntax tree. In: AICS, pp. 362–373 (2018)

Download references

Acknowledgements

This work was supported as part of the Next Generation Security Leader Training Program (Best of the Best) funded by Korea Information Technology Research Institute (KITRI).

Funding

This work was supported as part of the Next Generation Security Leader Training Program (Best of the Best) funded by Korea Information Technology Research Institute (KITRI).

Author information

Affiliations

Authors

Contributions

All authors contributed to the study conception and design. Material preparation, data collection and analysis were performed by H.Y.K., J.H.K., H.K.O., B.J.L. and S.W.M.. The first draft of the manuscript was written by H.Y.K. and J.H.K., and all authors commented on previous versions of the manuscript. All authors read and approved the final manuscript.

Corresponding author

Correspondence to Kyounggon Kim.

Ethics declarations

Conflict of interest

The authors declare that they have no conflict of interest.

Ethical approval

This article does not contain any studies with human participants or animals performed by any of the authors.

Informed consent

This article does not contain any studies with human participants.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Appendix A: Mitigations for prototype pollution vulnerability

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.

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.

figurex
figurey

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.

Appendix A.2: Make “__proto__” empty

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

figurez

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.

figureaa
figureab

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.”

figureac

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.

figuread

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.

figureae

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.

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Kim, H.Y., Kim, J.H., Oh, H.K. et al. DAPP: automatic detection and analysis of prototype pollution vulnerability in Node.js modules. Int. J. Inf. Secur. (2021). https://doi.org/10.1007/s10207-020-00537-0

Download citation

Keywords

  • Node.js security
  • Automatic vulnerability extrapolation
  • Source code analysis
  • Prototype pollution