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 & MonitoringAll 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:
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
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:
Counting lines of code in your project
Auditing your code to see if there are any known vulnerabilities
Linting and static analysis of your code inside your editor
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. 😉
Finally, your comments and suggestions are much appreciated.