How to Get Started with Secure Code Review

Since starting my secure code review challenges in December 2023 (https://github.com/dub-flow/secure-code-review-challenges), many people have asked me for some advice on how to get started with secure code review. Although I don't have a perfect answer for that question, I’ll try to provide some general ideas in this article.

I would generally say that learning secure code review consists of 3 phases:

1. Learn how to write code
2. Learn how to read other people’s code
3. Learn to identify vulnerabilities in code

Phase 1: Learn How to Write Code

I think it’s impossible to be great at secure code review if you have never written any code. Now I’m not saying you have to be a fully-grown software developer, but you should at least have some understanding of programming basics and develop a programmer’s mindset. This is important to understand other people’s code once you reach Phase 2.

So how to get started?

If you have never written a line of code before, then you’ll have a long journey ahead. There are a ton of free tutorials out there on how to get started so I won’t go into detail here.

Once you grasp basic programming concepts, I would recommend coming up with some pet projects just to get your hands dirty with code. It doesn’t really matter so much what kind of project it is, but it might make sense to focus on one technology stack and stick with it for a while. This could mean developing a few mobile, web, or desktop apps.

It’s been a looooong time since I started coding, but here are some of the pet projects that I remember doing.

Web Apps:

When learning how to do web development, I wrote 2 simple web apps from scratch (without using any frameworks) that would do the following:

1. An app that allows managing quotes. So basically whenever one of my colleagues (or I) says anything funny, or dumb, or in any other way memorable, my team would immortalize it in this app. This was basically CRUD functionality for quotes as well as user management and required me to write raw PHP, HTML, CSS, and JavaScript.
2. Another app I wrote was to manage PEBKACs (“Problem Exists Between Keyboard and Chair”). So say you get a coffee, go back to your desk, and accidentally spill it all over your keyboard… You want to make sure that people remember that, so my app allowed us to save it forever.

Desktop Apps:

So my focus has always been web, but I remember implementing Windows calculator myself with a GUI in C#, which I think is a great project to get started with implementing desktop apps.

Mobile Apps:

I haven’t done a lot of mobile development so far, but I’d say you could easily just write an app for the web projects above.

What other projects?

It really doesn’t matter what you write. As long as you get in the trenches and start writing code. If you don’t want to come up with something yourself, note that there is also a ton of suggestions out there, such as https://github.com/salmer/CppDeveloperRoadmap/blob/main/English/PetProjects.md (contains suggestions for pet projects to get started with programming).

Phase 2: Learn How to Read Code

Once you understand basic programming concepts, you can start with Phase 2. One thing you will realize is that it’s quite easy to understand your own code (at least if it hasn’t been too long since you wrote it 😃), but understanding other people’s code is much harder. So how can you get started with this?

The answer may or may not surprise you: You have to read other people’s code. There are like trillions of lines of open-source code out there and it frankly doesn’t matter too much whose code you read. Now, same as with learning a language, there will be a learning curve here. But it’s important to note that you don’t have to be perfect at reading code, it’s just that the more you practice, the easier it will be and the faster you will be able to read through code.

Also note that there are (at least) 2 types of code reviews:

1. Understanding what exactly the code does. This requires more time and practice
2. Understanding how data flows through an app and what kind of validation/encoding/etc. is applied

It may come as a surprise, but you don’t necessarily need to understand exactly what the code does to perform secure code review. Often, it’s sufficient to understand how data flows through an app, identify e.g. what validation is applied, understand what that validation does, etc.

Let’s take my second secure code review challenge as an example:

This code is vulnerable to Server-side Request Forgery (SSRF), which is a vulnerability that lets an attacker make a server send unintended requests to internal or external systems, potentially accessing sensitive data or services. This could e.g. allow a bad guy to access your internal applications (or a lot of other bad stuff, but let’s focus on secure code review for now).

Now what does the code actually do?

So there is the /fetch-data REST endpoint which allows passing in a URL via the query string. The app then performs a GET request against this URL, and sends the response body back to the user. Why would the developers do this? Well, there could be a ton of reasons. The most likely one, I’d say, is that they maybe have an external API (the Node.js app you see in the code snippet) for users to interact with. And then this Node.js app talks to a bunch of internal APIs that the developers don’t want to expose to the internet.

Now if you understood this that’s great, but to identify the vulnerability, you really don’t need to fully understand the code.

How does data flow through the app?

Instead, figuring out how data flows through the app is enough. So there is the /fetch-data REST endpoint which allows passing in a URL via the query string. The URL is stored in const url, which is then — without any validation — passed to axios.get(url). This means that an HTTP request is performed against it. The response of the HTTP request is stored in const response, which is then sent back to the user on line 25.

Just understanding how data flows through an app is much easier than understanding what the code actually does. And, many times, this is enough to identify a vulnerability via secure code review.

By the way, this is exactly how Static Analysis works: Data-flow analysis. But that’s a topic for another day.

Phase 3: Learn How to Perform Secure Code Review

Okay, let’s get to the juicy stuff and the reason you’re reading this article: Secure Code Review. Once you have basic code review skills, the next logical step is trying to identify vulnerabilities in code.

Unfortunately, there isn’t a lot of beginner-friendly material to learn secure code review out there. I know Hack The Box has some material (but I haven’t done it so I can’t speak to it). PentesterLab also has some material but I haven’t done that either so I’m not sure how beginner-friendly it is. The only thing I have done on the topic is OSWE (back in 2021), which is nice but would be difficult if you’re new to reading code.

If you want to get an idea on common types of vulnerabilities, and how they manifest themselves in code, I would strongly recommend doing my secure code review series: https://github.com/dub-flow/secure-code-review-challenges.

This gives you the basics but doesn’t provide you with a methodology on how to navigate through big apps. To traverse through big apps, Regex is your best friend. Open a code base in VSCode and search for entry points (e.g. GET/POST/PUT/PATCH/DELETE routes) and locations where untrusted data could be harmful (e.g. executing a SQL query with dynamic data).

A while ago, I wrote an article on how I used Regex to find over 20 CVEs in popular software: https://medium.com/@dub-flow/the-easiest-way-to-find-cves-at-the-moment-github-dorks-29d18b0c6900. This article will give you an idea of how to use Regex in the context of finding vulnerabilities.

I wish there was a beginner-friendly course that taught the methodology, but I’m not aware of anything right now, which naturally makes learning more difficult. I’ve even been playing with the idea of creating my own course, but that would be a massive time commitment, and video content isn’t really my medium yet so far. But we shall see.

Final Words

I hope that this article provides you with an idea of how to get started with secure code review.

Note that my secure code review challenge series is ongoing and I try to publish 1–2 challenges every month. If you want to stay up-to-date with my challenges, you may wanna follow me here on LinkedIn.