This article covers the left-over vulnerabilities from Part-1. In this article, we will have an in-depth look at some uncommon flaws and how to find them while doing performing code review of node.js applications.

Following are the list of vulnerabilities we are going to cover in this course:

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

• Global Namespace Pollution
• Cross Site Scripting
• Insecure Components
• Secure Code Review

Global Namespace Pollution:

When any variable or function is defined in a global scope as such other part of code is able to access and modify the same, this creates a confusion between different functions as whenever each function/ event is accessing that variable it will have different/same/overwritten values, such behaviour is called as global namespace pollution. This behavior can be exploited from the security point of view depending on the conditions and what type of value is being stored in the globally scoped variables/functions.

As can be seen, we have defined a variable called global, and we are simply incrementing and printing its value to the user.

However, the problem is whenever the user access this variable, its value will be incremented, and the new value will be shown to the user. This poses a security risk if session tokens are stored in global namespace with similar/different logic as an attacker can easily guess what will be the value of next session cookie being assigned to another user.

As can be seen, we have accessed the application from the different browser; the value is globally same for each client.

Cross Site Scripting

Cross Site Scripting occurs whenever untrusted user input in included in application response without proper validation. In case of node.js, there is no built-in pre-packaged module to overcome XSS attacks, leaving a novice developer to make mistakes and create exploitation opportunities for attackers.

As can be seen, we have coded a little snippet, that takes user input and append it to the string without proper filtering.

Further same can be exploited as follows:

To overcome XSS in node.js applications, we obviously need to implement context specific filtering for that we can use a package called html-entities which can be installed using the command line as npm install html-entities. Let's use this package in our app and execute the same payload.

As can be seen, our payload does not execute this time.

Insecure Components:

Insecure components cover all the third-party packages used by your application. It is very important from a security perspective to review their code before including them in your application. Go through the vulnerabilities section on their official website and make sure you are using the most updated and stable version of that package. Further, there are certain tools to automate this task, which we will discuss later in this section.

For demo purpose, we will be using the nodegoat application as it is using a vulnerable version of package name marked which is suffering from XSS vulnerability.

As can be seen, when the following payload is inserted, it interprets it as a link with JavaScript payload in its contents:

We can use already available tools such as snyk and npm-check to automate the task of identifying insecure and outdated components. To install these tool, execute the following command as the command line:

Let's execute these tools at our vulnerable nodegoat application and have a look at the output:

As can be seen, npm-check did flag some unused packages and tells us that marked package is outdated.

For using synk from the command line, you need to configure your account, after configuring our account we navigated to nodegoat's main directory and run the command snyk test.

As can be seen, it did find vulnerable packages and maked is one of them too.

Secure Code Review

Performing code review on larger application becomes a hectic job as it is not that easy to go through hundreds of lines of code. It is always recommended to perform semi-automated approach for code review like checking business logic manually and automating any repeated stuff that is looking for vulnerable function/packages/modules names, configurations. Make sure to check all functions where user input is being placed, file handling operations, Database queries, hardcoded credentials, insecure SSL/TLS versions in use, insecure crypto, global variables, etc. Further, we can use above tools snyk and node-check to look for any outdated or vulnerable packages.

Conclusion

From the vulnerabilities covered in this series, we can conclude that the source of most of the vulnerabilities is user input. Therefore, always filter and validate user input, always make sure appropriate middleware is in place to avoid any un-authorization flaws. This article will be incomplete without mentioning the awesome tool named "NodeJsScan" by Ajin Abraham. NodeJsScan is a static code analysis tool. It uses a set of regular expression rule at its core to scan for possible vulnerable code and misconfigurations; this also allows its users to extend the functionality of this tool using their own set of regular expressions. It is an exercise for the reader to download, configure and scan NodeGoat app using NodeJsScan and try to fix highlighted issues.

NodeJsScan can be downloaded from here.

References

https://www.npmjs.com/package/npm-check

https://snyk.io/blog/marked-xss-vulnerability/

https://www.npmjs.com/package/html-entities

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

https://github.com/ajinabraham/NodeJsScan