Manual code review helps with finding vulnerabilities that can stay hidden from automated tools.
This post describes my personal method of conducting manual reviews.

Doing a manual code review is not an easy task, it requires the auditor to have software development knowledge, working knowledge of the programming language used to write the code you’re going to audit, and a deep understanding of WHY vulnerabilities happen. Although you could review the code with having a basic to intermediate knowledge of the programming language but having a thorough understanding of the programming language you’re auditing code for is a huge advantage.

I’m going to explain 3 approaches, choose any one based on circumstances or do both.

Using grep

1. Find a list of dangerous functions in the programming language the code is written:
   • Functions for executing system commands
   • Functions that can be easily misunderstood or misused like PHP’s real_escape_string(It doesn’t escape `)
2. Find the values that are fed to these functions, Follow them back to their initialization point and check If they are
   • reachable in anyway from a user input point
   • sanitized enough before using.

Using a debugger

1. Run the program locally.
2. Attach an appropriate debugger for the language you’re reviewing, Most IDEs have can run and attach a debugger to the code.
3. Interact with the program inputs (http end points, stdin, file content etc)
4. In the debugger follow how the program processes the data by moving step by step through the code
5. Form hypothesizes about how you can exploit a weakness you think may exist
6. Test your hypothesis with an appropriate input
7. Repeat

Looking at Security Unit Tests

1. Look at the test suit written for the code if there’s any
2. Find tests specifically written for security like login, password reset, input sanitization etc
3. Try to find missed or blind spots that are not being tested for