Skip to main content

Holistic Approach to Code Review

These days I am doing code review. Good, I am learning one more new thing apart from Network scanning and Server security assessment. Code review is a very complex process. You have to be familiar with at least one language, rest of languages you will automatically learn as time passes.
Automated code review is a process where you run the scanning tools like Fortify on the code base followed by manual auditing of them. The scanner flags the whole code base with vulnerabilities based on its perception. Now its job of the auditor to differentiate between real issues and false positives. Here the real pain starts. You don't have command over each and very language. So taking help of the language specific resources is required. Now the situation is I have got familiar with almost all major language ( .NET, Java, PHP) specific vulnerabilities. Doing Black box assessment you never come to know , where the real problem lies. But Code review gives you the complete picture of the vulnerability and improves your security analysis ability. I am still a beginner in code review but I follow these processes to make it easier:

1. Always talk to developers first. The more you will involve developers in your code review process the more effective will be the analysis. You get confidence that whatever you are doing is based on right understanding of the code. On the other hand developers also get happy that you are taking him into confidence instead of declaring something vulnerable straightaway.

2. Have a note book and pen handy to understand the flow of the program. Understanding the source of the taint and where does it reflects in the code is necessary to catch the real vulnerabilities. Just seeing that the taint from user is entering the program and reflecting in some other part of the program doesn't always mean that it is vulnerable to Cross site scripting, for example. Again here, talking to developers benefit, as they might be implementing some centralized input filtering/validation mechanism. So don't just jump to any conclusion.

3. Use an advance text editor. The test editor should be capable of searching a term in the whole code base. One such text editor is Notepad++. It searches the term in whole code base and highlights them so that you can see where all places the particular term is being used. It helps you in joining the pieces and seeing the complete picture.

4. Have sufficient time to do code review as you need to apply your thoughts more than once to pick up real vulnerabilities. So always ask your customers for sufficient time.

5. Being connected to Internet always help at the time of code review. Certain terms, functions or methods always annoys you as you have may not have seen them before. Google helps a lot in understanding them.

6. Not only you should pick up real and applicable vulnerabilities in the context of the application- as it decreases the no. of issues- also you should propose the countermeasures in the report. That makes developers happy and confident.

7. Everybody loves his own program. Programs are like developers baby. Don't always pinpoint the weaknesses of the program, also appreciate them if you find any robust mechanism used in the program. That way you make them friendly and always they will come to use to get their code reviewed. So both happy.

8. The scanner may flag any issue as High, Medium or Low. It's your responsibility to give them appropriate ranking based on application's context.

9. Last but not least. Train developers about the vulnerabilities in real world. Give them training, involve them and encourage them to review their codes before production. Tell them how it saves efforts and money. If you have a scanning tool that supports plug ins for IDE, install at their machines so that they can do development and review hand by hand.

The above points are based on my little experience till date in doing code review. I have still a lot to learn and the points above may or may not hold true in every condition :)


Popular posts from this blog

File Upload through Null Byte Injection

Sometimes, during file upload we come across situation wherein there would be check on the file extension at the client side as well as server side too. If the application does allow only .jpeg extension to be uploaded, the client side java script checks for the extension of the file before passing the request. We all know that how easily this can be defeated.
Some applications, checks for the extension at the server side also. That's not easy to bypass. However there are some ways with which it still can be bypassed. Most of server side scripts are written in high level languages such as Php, Java etc who still use some C/C++ libraries to read the file name and contents. That leads to the problem. In C/C++ a line ends with /00 or which is called Null Byte. So whenever the interpreter sees a null byte at the end of the a string, it stops reading thinking it has reached at the end of the string.
This can be used for the bypass. It works for many servers, specially php servers. Th…

SQL Injection in search field

Earlier I had written about performing SQL injection in search field and how to do a DoS attack and privilege escalation using 'Like' operators. Now another SQLi exploitation I came across recently. That too in the search field. This becomes important as lots of people don't pay much attention on the search forms/ fields in the application. My aim is to show that a search form can also be exploited with SQL Injection. The following queries are based on a real world exploitation. The steps and data are for just illustration purpose only. Suppose, the search form provides the details of users who have accessed the application some time and their login time details etc, we just need to provide their name in the search box provided. All the data were being going as Post request. So, to just fingerprint the database, I provide, 'nil'+'esh' in the search field and it successfully gives me the results. That means the database behind the application is concatenat…

Insecure protocols

Some basic insecure protocols and risk associated with them: