Security is an illusion and being secure is a relative matter. This means you should always have an eye on your security from any perspective: Physical, human, social, corporate and IT security. Since any system, given enough resources — knowledge, tools and time, can be hacked.

My goal of writing this to show you how to approach and do a systematic secure code review and penetration testing for securing your Node.js and JavaScript apps which are very widespread nowadays. This being abundant enables attackers to have enormous amount of systems that are written in this language and that run on Node.js, browser and the like.

There are two different approaches on this: a) Secure Code Review as a defensive approach to find flaws in a system and trying to secure it. b) Penetration Testing as an offensive approach to find vulnerabilities and weaknesses on a live system.

A. Secure Code Review

Security code review is the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places. Code review is a way of ensuring that the application has been developed so as to be “self-defending” in its given environment. — OWASP Code Review Introduction

As you see, it’s all about auditing, verification and analysis. The OWASP community has proposed a good starting point to do this job. It is called “The OWASP Code Review Project”. It is an technical guide to help the code reviewers find the most flaws under a unified framework.

Two versions of this technical guide is published and version 2.0 being the most recent one, which was published 14 July 2017. The second version, which is thoroughly updated, consists of an introduction to the subject matter, a methodology and a set of technical references for the “OWASP Top 10” things to look for while reviewing code. Various diagrams, methods, risk models and techniques has been discussed. It is argued that the code review process should be a integrated into the Software Development Life-cycle (SDLC), from pre-commit to post-commit phases. Then a risk-based approach to code review has been proposed which tries to anlayze risk with different techniques. A set of code review preparation steps follows a set of static analysis tools. The last part show the S-SDLC as an “Application Threat Modeling” approach which consists of three steps:

Step 1: Decompose the application.
Step 2: Determine and rank threats.
Step 3: Determine countermeasures and mitigation.

Some tools for threat modeling has also been discussed. Lastly, a set of metrics are shown that can help the reviewer with quality and security characteristics of the code-base. Thereafter the code crawling practice is briefly introduced.

The technical reference section consists of the top 10 topics to consider while reviewing code:

A1-Injection
A2-Broken Authentication and Session Management
A3-Cross-Site Scripting (XSS)
A4-Insecure Direct Object Reference
A5-Security Misconfiguration
A6-Sensitive Data Exposure
A7-Missing Functional Level Access Control
A8-Cross-Site Request Forgery (CSRF)
A9-Using Components with Known Vulnerabilities
A10-Unvalidated Redirects and Forwards

This list is partly on par with what is known as the “OWASP Top 10 Project”, with some minor differences, which I do recommend both of these guides to anyone who wants to review code systematically, find flaws and eventually secure the system.

B. Penetration Testing

The second part, after reviewing code, is the penetration testing, which also consists of a set of steps to find and pinpoint vulnerabilities and weaknesses from an attacker’s point of view. Basically, you hack to secure!

A penetration test, colloquially known as a pen test, is an authorized simulated cyber-attack on a computer system, performed to evaluate the security of the system. — Wikipedia, Penetration test

Under the “OWASP Top 10 Project”, three different versions of a set of guidelines has been published up until now, with the most recent one being the 2017 version.

This guide consists of top 10 vulnerabilities to look for while testing an application/system:

A1:2017-Injection
A2:2017-Broken Authentication
A3:2017-Sensitive Data Exposure
A4:2017-XML External Entities (XXE)
A5:2017-Broken Access Control
A6:2017-Security Misconfiguration
A7:2017-Cross-Site Scripting (XSS)
A8:2017-Insecure Deserialization
A9:2017-Using Components with Known Vulnerabilities
A10:2017-Insufficient Logging & Monitoring

All these security risks may not be present all at once in one application, but one may lead to others and possibly to the compromise of the whole system or network.

There are a set of cheat sheets from the OWASP community that you can read to get an overview of what to expect while securing or testing a system:

Recommended Books:

C. Where to Look for Vulnerability Listings

There are many databases that list vulnerabilities and their information and relations. For example, if it is an open-source project, you need to visit the “Issues” section, either on GitHub, GitLab or elsewhere.

There are many bug trackers out there. Some of which are focused on security, e.g. https://security-tracker.debian.org/tracker/.

If it is a proprietary project, you usually should look for public databases, like the company’s website or these websites:

D. Programming Knowledge and Experience

It should never be underestimated that for great code review, one needs great programming skills, or at least, an understanding of what is used on the project. Since JavaScript ecosystem has been evolved over the years and many libraries, engines and practices has been developed, one can easily get lost in this vast amount of information.

I do recommend you to have a look at these two gold mines:

E. Tools of the Trade

Now that we have a solid ground in terms of methodology and knowledge to work on, we should look at the available tools that can help an reviewer/attacker do their job.

I just list these tools, which I have tested my projects with, and it is up to you to read the documentation and figure out how they work. They are very easy to use in my view.

I have stumbled upon https://github.com/mre/awesome-static-analysis, https://github.com/jesusprubio/awesome-nodejs-pentest and https://www.owasp.org/index.php/Source_Code_Analysis_Tools as an starting point for doing the static analysis of the code. Many tools are listed, some old and some new. What I used for my project is as follows:

For counting lines of code in your project, go with these two:

For auditing your code to see if there are any known vulnerabilities, have these a try:

For linting and static analysis of your code inside your editor, look at these:

Useful JavaScript libraries for secure development:

There are a bunch of cloud services that offer security as a service:

Most of what I recommended up until now was about secure code review. The following tools are useful for penetration testing:

Guidelines and best practices:

Now is your time to sharpen your swords ⚔️ and test them to be ready for attack. Be sure not to cut your fingers. 😉

Although I have presented ways to review code and penetration test on JavaScript and Node.js, the same principles and practices apply to other languages, too. You just have to look up the information on that language.

Finally, your comments and suggestions are much appreciated.

Mostafa Moradian
Developer Advocate 🥑 Load Impact
GitHub | LinkedIn | Twitter