Title:
5 Security Considerations When Coding

Word Count:
598

Summary:
1. Input Checking

Always check user input to be sure that it is what you expected. Make sure it doesn’t contain characters or other data which may be treated in a special way by your program or any programs called by your program.This often involves checking for characters such as quotes, and checking for unusual input characters such as non-alphanumeric characters where a text string is expected. Often, these are a sign of an attack of some kind being attempted.

Keywords:
security, coding, programming, php, hacking, c++, code, secure

Article Body:
1. Input Checking

2.Range Checking

Always check the ranges when copying data, allocating memory or performing any operation which could potentially overflow. Some programming languages provide range-checked container access (such as the std::vector::at() in C++, but many programmers insist on using the unchecked array index [] notation. In addition, the use of functions such as strcpy() should be avoided in preference to strncpy(), which allows you to specify the maximum number of characters to copy. Similar versions of functions such as snprintf() as opposed to sprintf() and fgets() instead of gets() provide equivalent length-of-buffer specification. The use of such functions throughout your code should prevent buffer overflows. Even if your character string originates within the program, and you think you can get away with strcpy() because you know the length of the string, that doesn’t mean to say that you, or someone else, won’t change things in the future and allow the string to be specified in a configuration file, on the command-line, or from direct user input. Getting into the habit of range-checking everything should prevent a large number of security vulnerabilities in your software.

3.Principle Of Least Privileges

This is especially important if your program runs as root for any part of its runtime. Where possible, a program should drop any privileges it doesn’t need, and use the higher privileges for only those operations which require them. An example of this is the Postfix mailserver, which has a modular design allowing parts which require root privileges to be run distinctly from parts which do not. This form of privilege separation reduces the number of attack paths which lead to root privileges, and increases the security of the entire system because those few paths that remain can be analysed critically for security problems.

4.Don’t Race

A race condition is a situation where a program performs an operation in several steps, and an attacker has the chance to catch it between steps and alter the system state. An example would be a program which checks file permissions, then opens the file. Between the permission check the stat() call and the file open the fopen() call an attacker could change the file being opened by renaming another file to the original files name. In order to prevent this, fopen() the file first, and then use fstat(), which takes a file descriptor instead of a filename. Since a file descriptor always points to the file that was opened with fopen(), even if the filename is subsequently changed, the fstat() call will be guaranteed to be checking the permissions of the same file. Many other race conditions exist, and there are often ways to prevent them by carefully choosing the order of execution of certain functions.

5.Register Error Handlers

Many languages support the concept of a function which can be called when an error is detected, or the more flexible concept of exceptions. Make use of these to catch unexpected conditions and return to a safe point in the code, instead of blindly progressing in the hope that the user input won’t crash the program, or worse!