I have worked as part of a team going into client locations and performing software security assessments. While analyzing the findings of these assessments I have seen a common set of coding omissions that, if implemented, would eliminate the majority of the vulnerabilities that were identified. A brief description of each follows.
- Input Validation
Data coming into an application from the outside is routinely trusted by developers. The source of the data can be anything from data or configuration files to direct user input. If the data is used directly from the input source unexpected results can occur. These can include but are not limited to SQL Injection, Cross Site Scripting and Cross Site Request Forgery. This situation can be avoided by validating the data before it is used. The validation can be as simple as comparing the value to a set of known, valid values. Validation could use regular expressions to determine if a value is valid. This type of check can eliminate certain characters that are known to cause problems and that will not be in any valid input value. It should become the default for a developer to include input validation anytime that any type of input comes into an application. - Error Handling
Error handling has always been an area of discussion with developers. A solid system for handling errors should be a part of any applications design. All too often though this gets left out entirely or only has a loose implementation that does not account for all errors. For web applications it is especially important to include custom error handling as opposed to allowing the default error handling to take place. Default error handling usually discloses information about the application that the user has no business seeing. For most users it will be meaningless but for potential attackers it could be the very piece of the puzzle that allows them to perform a successful attack. Information that is typically leaked include database table names and column names, SQL statements, program stack traces as well as other information. Implementing a custom error handling system that discloses very little about the application itself will avoid such information leaks. - Freeing Resources
Improperly managed system resources is another area that seems to get omitted often. Whether it is allocated memory or open file handles/descriptors, system resources should be given proper management. When this need is ignored or mishandled it can lead to a denial of service attack due to system resources becoming unavailable and the server becoming unresponsive. Directly freeing the resources after a successful use of the resource should be done by the developer. This is the “easy” part of resource management. The part that is most often overlooked is the unexpected cases where, due to an error condition, the program execution path takes a direction that leaves the resource allocated although it will not be used again. These situations should be addressed in the application so that all execution paths will result in the proper freeing of unused resources.
Of course there are other types of findings when performing the software security assessments but in my experience these three have stood out as being the most common.
