Seven Secure Programming Tips
The purpose of the following series of articles is to aid you, the developer, in creating more secure applications. These articles do not assume any programming or security expertise, nor are the contents focused on any specific programming language or technology. This article contains tips for beginning and advanced developers, and it doesn’t matter if you develop in .NET, Java, PHP or any other of the numerous languages we use to develop applications. This series will be broken down into seven distinct articles. Each weekly article, listed below, will provide an overview of the pros and cons associated with its implementation, as well as how to handle them in a more secure manner.
· Week 1: Input Validation
· Week 2: Application Error Handling
· Week 3: User Feedback Messages
· Week 4: Cookie Creation and Session Management
· Week 5: Forgotten Password Requests
· Week 6: Handling File Uploads
· Week 7: Dangers of 3rd Party Controls
Week 1: Input Validation
Input validation is one of the simplest things a developer can implement to begin securing an application. Virtually all of the most well known injection attacks, such as SQL injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) and Null byte (%00) injection to name a few, can be prevented by implementing proper input validation techniques. As developers, we spend so much time focusing on the functionality of the application that the security of the application is often overlooked, or becomes something that is only thought of at the end of the development process. However, simple steps taken during development can go a long way toward having a more secure application. There are two well known techniques that can be used in implementing proper input validation. They are known as “Blacklisting” and “Whitelisting”.
Blacklisting is a technique that means all characters should be allowed, except those that are in the black list. Whitelisting is just the opposite, and means all characters should be disallowed, except for those that are in the whitelist. Let’s assume we have a textbox where the user should enter his or her full name (first and last) and, let’s also assume that we want our application to prevent known injection attacks, such as those mentioned earlier. First, we need to know which characters could be used in various injection attacks. For SQL injection we know characters such as the apostrophe (‘), octothorpe (#), also known as the pound sign, and the semi-colon (;) could be interpreted by various databases as command separators or comments. We know common HTML or Cross-Site Scripting injection attacks can be accomplished by using various characters, such as the greater than (>) and less than (<) signs, as well as double quotes (“). And we know Null byte injection attacks use the null byte (%00). We also know that all of the characters just mentioned can be encoded in any number of ways.
The blacklist approach to securing this “full name” field to prevent injection attacks would be to create a list of all possible characters that could be used maliciously. If you think about it, this would become a pretty extensive and time consuming list to create, taking into consideration the number of characters we want to prevent, as well as their encoded counterparts. We could write regular expressions for each possible character scenario that would cause our application harm. In the end we would have spent a vast amount of time attempting to prevent various characters from being allowed in a single field. Granted we could probably use this list to validate input in other fields, but just making the list would be very time consuming.
The whitelist approach, on the other hand, is much simpler and much more efficient. The steps we would need to take would be to determine the valid characters we want to allow. Assuming the application only accepts English characters, we can consider what characters should be used in creating a person’s name. First, we would obviously want to allow characters a-z and A-Z. Second, we should consider those people who have names containing apostrophes (‘), to handle such last names as O’Neil or D’Arban. Finally, we should consider those individuals who have hyphenated names, such as Nancy Smith-Jones or Maurice Jones-Drew. In the end we are looking at allowing only four unique sets of characters (a-z, A-z, ‘, -). That’s a pretty small and quick list to create. We might also consider creating a blacklist to supplement our whitelist. We have already stated that alpha characters (A-Z) are allowed. However, there are words that could cause our application harm. Words such as INSERT, UPDATE and DELETE could lead to a SQL injection attack, since we are allowing apostrophes (‘). We should obviously take steps to escape the apostrophe, as well as disallow the use of inline SQL in our application. By combining both blacklisting and whitelisting we can ensure the user is supplying only valid characters.
One common issue developers make is where they perform the validation on the user-supplied input. Some developers may validate the input only on the client-side using JavaScript, which is convenient for the user, as it provides immediate feedback for any input errors. Other developers may validate the input only on the server-side once the page has been posted back to the server. This obviously isn’t very convenient for the user, as they have to wait for the response from the server to know if there are any input errors. The simple fact is input validation should be performed on both the client and the server. You should never perform client-side validation only as it is generally dependent upon the user having JavaScript enabled in their browser. If the user turns off JavaScript, they also turn off your validation process. In the end, proper input validation should consist of a properly implemented whitelist, which might be supplemented by a blacklist, and ensuring that the input validation is occurring on both the client, as well as the server.