Jan. 25, 2011, 1:42 p.m.
posted by creed
On occasion you will have the benefit and challenge of performing remediation via a totally whitebox code audit. If there is great risk surrounding the code and target application, you must gauge whether or not it is worth it. The target entity may be better served with edge-level protection as discussed earlier in this chapter. But in the event the client actually wants the code fixed, there are some things you should focus on. One of the dangers of remediation of legacy code is that the effort subtly turns into an application re-write project. It is obviously up to you to accept or decline that.
Code audits are obviously subjective based on the target. As such this topic cannot be covered deeply. Security audits of source code are not lightweight efforts and certainly cannot be covered in a small section of one chapter. You can get started with RATS (Rough Auditing Tool for Security — https://securesoftware.custhelp.com/cgi-bin/securesoftware.cfg/php/enduser/doc_serve.php?2=Security) though. It supports Perl, Python, PHP, and C/C++ source code. It will at least give you a rough idea of what security auditing source code is like. As an example here is a small snippet of insecure PHP source code (to be saved in a file called php_fopen.php for the example) to get you going:
<? php $theFileName = "testFile.txt"; $fh = fopen($theFileName, 'w') or die("Can't open file"); fclose($fh); ?>
Running RATS in its simplest form alerts you to a potential problem with fopen:
rats -l php php_fopen.php Entries in perl database: 33 Entries in python database: 62 Entries in c database: 334 Entries in php database: 55 Analyzing php_fopen.php php_fopen.php:3: High: fopen Argument 1 to this function call should be checked to ensure that it does not come from an untrusted source without first verifying that it contains nothing dangerous. Total lines analyzed: 6 Total time 0.001335 seconds 4494 lines per second
In the example the filename is statically set; if that data were coming from input of any source you would have to deeply scrutinize that source. You would be looking for any potential for malicious data injection in any of the many ways you have seen throughout this book. Then you would inject some malicious data such as that in Appendix D and see how the PHP code and web server react. Taking this simple example deep into all potential issues and out across the breadth of an entire Web app is what a true source code audit would be like. The documentation and respective recommendations would be similar what you saw in Chapter 9 and what you have seen in this chapter as well.