Printer Friendly Version

Writing secure code is the first step in producing applications that are secure and robust. For custom applications that are already written, and commercial off-the-shelf (COTS) products, tools exist to audit for existing security deficiencies. Understanding the security vulnerabilities that exhibit themselves in existing products allows you to make better-informed decisions on patching and enables you to come up with other strategies to make these weak links in your infrastructure more secure.

Coding New Applications to Make Them Secure

Many security vulnerabilities could easily be prevented if security were taken into consideration at the beginning of the development process. While it is nearly impossible to come up with a list of every possible vulnerability that could exist as a result of coding oversights, it is possible to understand some of the more typical and common problems that often exhibit themselves as coding weaknesses and vulnerabilities.

When identifying coding weaknesses in applications, it is often the case that the same overlooked principles exhibit themselves time and time again. While you can't test your new application for every security vulnerability under the sun, you can in fact avoid the more common causes for security vulnerabilities to protect your new applications from the most obvious exploits.

Common Problems You Should Try to Avoid

By working to prevent some of the more overt security coding blunders, your chances of producing a secure application increases dramatically. Most of the typical security coding gaffes that you should try to avoid when coding in C, C++, Visual Basic, or any leading programming language, can also be applied to JavaScript, Perl, and other scripting languages. Some of the most common security problems that you should try to avoid when writing new code or scripts are:

• Weak file and group permissions
• Race conditions
• Buffer overflows
• Problems with temporary files
• Overly complex and unnecessary code
• Insecure system calls and switches
• Hard-coding passwords

According to Steve Bellovin, a renowned security researcher working at Bell Labs, "permission checking cannot be separated from access." What Mr. Bellovin means by that is that read, write, and execute permissions on programs play a deterministic role in what types of data users can access.

Account and group ownership of various programs determine which users can run the programs, and which users can access the data that the programs use or produce. If a miscreant end-user has the ability to create confidential information using insecure programs, the confidential information could lack safeguards and has the potential to be exploited at some point in the future.

Race conditions occur when the outcome of interrelated events depend on a particular event ordering sequence that cannot be guaranteed making the final state of the system unpredictable. A particular programming practice that can help prevent race conditions is to not start reading a file while it is still being written to by another process.

Buffer overflows occur when hackers inject arbitrary code into assigned application buffer spaces causing unwanted executions of applications. Buffer overflows can be prevented by making sure that bounds checking is done on the length of input variables, arrays, and arguments.

Certain applications create temporary files at the beginning of their execution for the purpose of being used later for parsing logging or other information. However, if the temporary file does not have secure permissions, it could be altered between the time it is created and the time the program later reads from it or writes to it again creating opportunities for exploitation.

Overly complex code is much more difficult to secure. Always keep it simple. Keep in mind that in developing future versions of the application, or during bug fixes, developers who didn't initially write the code may be the ones trying to secure it. The more lines of code there are, the greater the probability that security vulnerabilities will be created.

Using insecure switches or system calls can create opportunities for unauthorized users to exploit vulnerabilities. Some system calls spawn subroutines or shell commands that do not take into consideration secure path and environment variables that are used by the mother program. Insecure system calls may also inadvertently allow unauthorized read and write executions to be initiated. One safeguard against insecure system calls is to create a "sandbox," which encloses the child process or subroutine in a safe environment where it cannot be exploited.

Hard-coding passwords into programs is probably the worst coding sin a developer can commit. Developers should never hard-code passwords into programs. If passwords are hard-coded into programs, it is possible that unauthorized users can discover them using sniffers or protocol analyzers.