An Oxymoron : Static Analysis of a Dynamic Language (Part 2)
An Oxymoron : Static Analysis of a Dynamic Language (Part 2)
From client side JavaScript to server side NodeJs
Now that you have reached here after reading the prior post , lets switch contexts and examine the server side javascript landscape.
JavaScript has also become increasingly popular for platforms beyond the browser i.e. server-side (Node.js based).
One of the forces behind using JavaScript in other domains is to enable client-side programmers to reuse their skills in other environments.
Unfortunately, this skill transfer also spreads the risk of misusing JavaScript in a way that threatens software security. Some of the bad habits of client-side JavaScript creeps into server side development. As a consequence new vulnerabilities and kinds of attacks become possible, which do not directly map to problems known from the client-side.
Node.js is a novel event-based network application platform which forces developers to use asynchronous programming interfaces for I/O operations. The native language for developing applications on this platform is JavaScript. The Node.js community generally has a strong focus on the scalability of the platform. However, little research has been done on how the platform’s design decisions affect the security of its applications.
An important characteristic of modern node.js based applications is the extensive use of third-party libraries. On the npm platform over 1 million packages (mostly libraries) are available, and only a few of them have been screened intensively for security vulnerabilities. A challenge when analyzing the security of npm packages is that they are often not self-contained, but they in turn transitively depend on other npm packages for providing lower-level functionality. Statistics show that, on average, every npm package depends on 79 other packages and on code published by 39 maintainers . To correctly understand an application that uses npm packages, one needs to cohesively consider all these dependencies.
According to a security survey by npm, 77% of respondents were concerned with the security of OSS/third-party code.
Embedded below is a spreadsheet listing the top ‘x’ open source libraries sorted by utility dimensions
Two main directions are being pursued for automatically securing npm packages. First, there are tools that aggregate known security vulnerabilities in specific versions of individual libraries and report them to the developer directly. For example, npm audit analyzes all the dependencies of a Node.js application and warns the developer about any known vulnerabilities in the dependent-upon code. GitHub, Snyk, and other companies offer similar services.
The main limitation of this approach is a limited scoped view leading to high number of false positives
Often the critical part of the library is not used by the application, or it is used in a way that is completely harmless. For example, an application may use an npm module vulnerable to command injection attacks, but it passes only string constants provided by the developer as input to this module. We believe it is important to make the distinction between merely relying on a library that contains a potential known vulnerability and using that library in an insecure way. Another problem with these tools is that libraries that use insecure features of the JavaScript language or of the Node.js framework are often not registered as having “known vulnerabilities” if their documentation indicates that these features are being used internally.
By analyzing security issues reported in the past and through developer interactions, it has been observed that developers who use and maintain JavaScript libraries are generally reluctant to use analysis tools and are not always willing to fix their code. A dynamic we have seen developing is a blame game between Node.js module maintainers and developers who use these modules, where each party tries to claim that the other is responsible for checking untrusted input. Furthermore, while an individual developer can find it tempting to deploy a local fix to a vulnerable module, this patch is likely to be made obsolete or will simply be overwritten by the next module update.
As a result of Node.js increasing popularity, there has been a growing demand for tools that assist programmers with tasks such as detecting and preventing security vulnerabilities.
In the next part of this series we will examine the evolution of new standards that has taken shape to address these issues.
An Oxymoron : Static Analysis of a Dynamic Language (Part 2) was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Chetan Conikee. Read the original post at: https://blog.shiftleft.io/an-oxymoron-static-analysis-of-a-dynamic-language-part-2-d150b393e551?source=rss----86a4f941c7da---4
