Code Review Methodology

While practicing performing code review, I have found there a good methodology is a cyclic process that repeats itself again and again. There are 3 steps:

1. Planning
2. Reviewing Code
3. Reviewing the process

Planning Stage

This part of the process is fairly simple. The useful things to have at this stage is understanding what you know about the application. It is up to you how to organize this. These are some of the lists I like to keep:

• List of use cases of the application.
• List of technologies used.
• List of interesting features in the application.
• List of possible attack vectors.
• List of features tested.

The most important lists to work on are the list of possible attack vectors and what has been tested. This will ensure that your time spent will be productive.

The biggest goal of the planning process is picking an objective to complete. This will be the focus of the current cycle and will ensure you do not get stuck down rabbit holes. Here are some examples of goals:

• Enumerate how the log in page works.
• What functions are involved in the file upload.
• Understand where the files are stored.

Reviewing Code

Find a starting point:
The first part of this stage is understanding where to find the relevant code. There are multiple ways to identifying where to find the relevant code. Here are some methods that I have found to be effective.

1. Use key words from the application to identify files that may be relevant.
2. If it is a form, the variables when the form is submitted may be used as a starting point.
3. There may be words in the request path/variables that may be functions.
4. Go through the structure of the application. It may be quite easy to navigate.
5. Try to navigate the flow of the code from when it is entered in the view. Or the other way round.

Reading the code:
This part will take a while. Depending on how proficient you are with the language, it may take some time to do this. Here are some tips on reviewing the code:

• Google everything! This will make it easier for you to understand what is happening. Looking through documentation will really help.
• Set the application in debug mode so you can view how variables are affected during run time. You can look in areas such as log files and printing alert boxes.
• If you’re really stuck, extract the code and create a test program to understand what is happening.
• If the goal of the current process requires something like a general understanding of the flow of the code. There is no need to go fully in depth. Mapping out what functions are called where and how they interact would be good enough.

Reviewing the process

After the code is reviewed, it is important to reconcile all the knowledge that has been gained. This includes things such as:

• Understanding the structure of the files and functions.
• Interesting functions that may be useful.
• Possible attack vectors that may be used.

Update all the information you have gained so that in the next planning phase, a strategy based on more information can be formed.

Here are some tips for the whole process:

• The initial processes may not find much. This is because you need to grow your knowledge the application. After this phase, you will be able to craft slightly more complex attack vectors.
• Taking regular breaks helps a lot.
• Learn how the developer writes their code. For example, if a developer really enjoys using blacklists, that may really help craft an attack vector.
• Not each cycle will give you a vulnerability. However, the knowledge gained is just as important.
• Update your notes as frequently as possible.

Thank you for reading, let me know if you have any ideas you can add to this.