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 :)
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 :)
Comments