Defensive programming

related topics
{system, computer, user}
{math, number, function}
{law, state, case}
{work, book, publish}
{theory, work, human}
{war, force, army}
{game, team, player}
{specie, animal, plant}

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy's Law having effect. Defensive programming techniques are used especially when a piece of software could be misused mischievously or inadvertently to catastrophic effect.

Defensive programming is an approach to improve software and source code, in terms of:

  • General quality - Reducing the number of software bugs and problems.
  • Making the source code comprehensible - the source code should be readable and understandable so it is approved in a code audit.
  • Making the software behave in a predictable manner despite unexpected inputs or user actions.

Contents

Secure programming

Defensive programming is sometimes referred to as secure programming by computer scientists who state this approach minimizes bugs[citation needed]. Software bugs can be potentially used by a cracker for a code injection, denial-of-service attack or other attack.

A difference between defensive programming and normal practices is that few assumptions are made by the programmer, who attempts to handle all possible error states. In short, the programmer never assumes a particular function call or library will work as advertised, and so handles it in the code. An example follows:

int low_quality_programming(char *input){
  char str[1000+1];     // one more for the null character
  // ...
  strcpy(str, input);   // copy input
  // ...
}

The function will crash when the input is over 1000 characters. Many mainstream programmers may not feel that this is a problem, supposing that no user will enter such a long input. A programmer practicing defensive programming would not allow the bug, because if the application contains a known bug, Murphy's Law dictates that the bug will occur in use. This particular bug demonstrates a vulnerability which enables buffer overflow exploits. Here is a solution to this example:

int high_quality_programming(char *input){
  char str[1000];
  memset(str, 0, sizeof(str));    // initialize the string NUL characters
  // ...
  strncpy(str, input, sizeof(str) - 1); // copy input, always leaving room for a NUL character
  // ...
}

[edit] Techniques

Here are some defensive programming techniques:

[edit] Reduce source code complexity

Never make code more complex than necessary. Complexity breeds bugs, including security problems. This goal can conflict with the goal of writing programs that can recover from any error and handle any user input. Handling all unexpected occurrences in a program requires the programmer to add extra code, which may also contain bugs.

[edit] Source code reviews

A source code review is where someone other than the original author performs a code audit. A do-it-yourself security audit is insufficient: the review must be made by a non-author, just as when writing a book, it must be proofread by someone other than the author.

Simply making the code available for others to read (see Free software or Open Source Definition) is insufficient: there is no guarantee that the code will ever be looked at, let alone that it will be rigorously reviewed.

[edit] Software testing

Software testing should be performed to make sure the program handles unexpected input appropriately.

Testing tools can capture keystrokes associated with normal operations, then the captured keystroke strings can be copied and edited to try out all permutations of combinations, then extended for later tests after any modifications. Proponents of key logging state[citation needed] that programmers who use this method should make sure that the people whose keystrokes are being captured are aware of this, and for what purpose, to avoid accusations of privacy violation.

[edit] Intelligent source code reuse

If existing code is tested and known to work, reusing it may reduce the chance of bugs being introduced.

However, reusing code is not always a good practice, particularly when business logic is involved. Reuse in this case may cause serious business process bugs.

[edit] Legacy problems

Before reusing old source code, libraries, APIs, configurations and so forth, it must be considered if the old work is valid for reuse, or if it is likely to be prone to legacy problems.

Legacy problems are problems inherent when old designs are expected to work with today's requirements, especially when the old designs were not developed or tested with those requirements in mind.

Full article ▸

related documents
One instruction set computer
COMMAND.COM
Dhrystone
Lotus Improv
Wikipedia:Free On-line Dictionary of Computing/O - Q
XUL
Yabasic
Enterprise Objects Framework
Active Server Pages
Internet standard
ANSI escape code
ACID
Netlist
Basic Encoding Rules
CPAN
Abstract machine
Hello world program
Universal Turing machine
Code
Troff
Erlang unit
Ada (programming language)
Third-order intercept point
Streaming SIMD Extensions
Escape sequence
Parallel algorithm
Object Linking and Embedding
NeWS
Queueing theory
Simula