3-3 Source Code Review

While exploit research technically covers source code review, it also deserves its own section as it as it can pop up in multiple places and covers a wide range of potential sources, whether that's because you can find public repositories for the tools in use, leaked source code, or were directly provided it as part of the lab. Plus the utility of seeing the source code applies for both understanding the behavior the application (enumeration) and the finding and testing of exploits.

Source code review is a very large subject, and for this initial draft I won't go deep into it. A few general comments about what to consider looking for in source code though:

1. Secrets. Hard coded secrets may be present, whether in comments or directly in the code.
2. Information that points to where configuration info, including said secrets, may be stored if they aren't found in the source.
3. Dependency information: whether specific libraries, and their versions are used, which can then be exploited.
4. Vulnerabilities introduced directly in the code. There are a wide variety that can be considered here, but look particularly for:
   • unsafe functions like eval(), exec(), etc.
   • any location where user input is accepted. Is the user input validated or filtered or not? Does the user input get used elsewhere in a function that invokes business logic or interacts directly with systems?
   • Information on any use of cryptography and its implementation for logic errors or weak algorithms.
   • Improper use of memory management that opens the door for buffer and heap overflows (I have limited experience with these currently).

There are undoubtedly others not mentioned here.