5 Security Considerations When Coding

Print Version
Share to a friend

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.


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!