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.
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:
A2-Broken Authentication and Session Management
A3-Cross-Site Scripting (XSS)
A4-Insecure Direct Object Reference
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:
A3:2017-Sensitive Data Exposure
A4:2017-XML External Entities (XXE)
A5:2017-Broken Access Control
A7:2017-Cross-Site Scripting (XSS)
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:
The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific…
Defensive Security Handbook
Despite the increase of high-profile hacks, record-breaking data leaks, and ransomware attacks, many organizations…
Securing Node Applications
Security incidents are indeed on the rise, but according to one authoritative analysis, 85% of all successful exploits…
Dr. Axel Rauschmayer Blogger ( 2ality), book author, trainer
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:
Offensive Security's Exploit Database Archive
The Exploit Database - Exploits, Shellcode, 0days, Remote Exploits, Local Exploits, Web Apps, Vulnerability Reports…
CVE - Common Vulnerabilities and Exposures (CVE)
Common Vulnerabilities and Exposures (CVE®) is a list of entries - each containing an identification number, a…
CVE security vulnerability database. Security vulnerabilities, exploits, references and more
CVEdetails.com is a free CVE security vulnerability database/information source. You can view CVE vulnerability…
NVD - Home
NVD is the U.S. government repository of standards based vulnerability management data represented using the Security…
D. Programming Knowledge and Experience
I do recommend you to have a look at these two gold mines:
zap: Delightful Node.js packages and resources. Contribute to sindresorhus/awesome-nodejs development by creating an…
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:
Compare the amount code in your application vs. in its `node_modules` folder
For auditing your code to see if there are any known vulnerabilities, have these a try:
Open Source Security Platform | Snyk
Snyk helps you use open source and stay secure. Continuously find and fix vulnerabilities for npm, Maven, NuGet…
Audits an NPM package.json file to identify known vulnerabilities. - OSSIndex/auditjs
NodeJsScan is a static security code scanner for Node.js applications. - ajinabraham/NodeJsScan
Engineering Metrics to Improve Continuous Delivery Practices | Velocity
Code Climate provides automated code review for your apps, letting you fix quality and security issues before they hit…
For linting and static analysis of your code inside your editor, look at these:
A list of awesome ESLint plugins, configs, etc. Contribute to dustinspecker/awesome-eslint development by creating an…
An eslint plugin to find strings that might be secrets/credentials - nickdeis/eslint-plugin-no-secrets
ESLint rules for Node Security. Contribute to nodesecurity/eslint-plugin-security development by creating an account on…
ESLint plugin for XSS detection. Contribute to Rantanen/eslint-plugin-xss development by creating an account on GitHub.
SonarJS rules for ESLint. Contribute to SonarSource/eslint-plugin-sonarjs development by creating an account on GitHub.
umbrella config to achieve scanjs-like functionality through eslint - mozfreddyb/eslint-config-scanjs
There are a bunch of cloud services that offer security as a service:
Cloudflare - The Web Performance & Security Company | Cloudflare
Register for Internet Summit 2018 Cloudflare's Anycast network keeps your website, app, or API online and running…
Application Security Management Platform | Sqreen
Sqreen's Application Security Management Platform offers a modern approach to security in production for web…
Leading Website Vulnerability Scanner | Detectify
Detectify is a website vulnerability scanner that performs tests to identify security issues on your website. Let us…
Most of what I recommended up until now was about secure code review. The following tools are useful for penetration testing:
sqlmap: automatic SQL injection and database takeover tool
sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection…
Burp Suite Scanner | PortSwigger
PortSwigger offers Burp Suite for security testing & scanning. Choose from a wide range of security tools & identify…
OWASP Zed Attack Proxy Project - OWASP
The OWASP Zed Attack Proxy (ZAP) is one of the world's most popular free security tools and is actively maintained by…
Nmap: the Network Mapper - Free Security Scanner
Nmap Free Security Scanner, Port Scanner, & Network Exploration Tool. Download open source software for Linux, Windows…
Postman | API Development Environment
Postman is the only complete API development environment used by more than 6 million developers and 200,000 companies…
Now is your time to sharpen your swords ⚔️ and test them to be ready for attack. Be sure not to cut your fingers. 😉
Finally, your comments and suggestions are much appreciated.