Defensive programming: Difference between revisions

Revision as of 03:58, 24 June 2004

Revision as of 19:27, 15 August 2004

Line 1:

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 that piece ofsaid software. The idea can be viewed as reducing or eliminating the prospect of [[Murphy's Law]] having effect. Defensive programming techniques come into their own when a piece of software could be misused mischievously or inadvertantly to catastrophic effect.

Here are some hints on '''defensive programming techniques''' to avoid creating security problems.

Many of these techniques also improve general quality of code, because almost any major bug can be potentially used by a [[cracker (computing)|cracker]] for a [[Denial of Service]] or other attack.

for a [[Denial of Service]] or other attack.

Note that the techniques below are ''not'' sufficient to ensure security: see the articles [[computer insecurity]] and [[secure computing]] for more information.

Line 11 ⟶ 10:

<!-- Please expand this article. These random notes should be changed to a more coherent article. -->

* One of the most common problems is unchecked use of constant-size structures and functions for dynamic-size data (the [[buffer overflow]] problem). This is especially common for [[string]] data in [[C programming language|C]]. C library functions like <tt>gets</tt> and <tt>scanf</tt> should never be used since the maximum size of the input buffer is not passed as an argument.

* Never make your code more complex than necessary. Complexity breeds bugs, including security problems.

You should never use functions like <tt>gets</tt> and <tt>scanf</tt>.

* Either leave yourthe code available to everyone on the Net (see [[Free software]] or [[open source definition]]) or hire someone who will doperform a software [[security audit]] for you.

* Never make your code more complex than necessary. Complexity breeds bugs, including security problems.

* Either leave your code available to everyone on the Net (see [[Free software]] or [[open source definition]]) or hire someone who will do [[security audit]] for you.

* If possible, reuse code instead of writing from scratch.

* Encrypt all important data which flow the Net.

* All data is important until proved otherwise.

* All code is unsecure until proven otherwise.

* Never make your programprograms [[setuid]] unless you're <b>really</b> sure it's secure.

*If youdata checkis datachecked for correctness, checkverify if it's correct, not if it is incorrect.

Crackers are likely to invent new kinds of incorrect data. For example, if

you checked if a requested file is not "/etc/passwd", a cracker might pass another

Line 26 ⟶ 24:

----

Preconditions, Postconditions and Invariants validation are also part of Defensive Programming. This may involve checking arguementsarguments to a function or method for validity before execution of the body of the function. After the body of a function, doing a check of object state (in OO languages) or other held data and the return value before exits (break/return/throw/error code) is also wise.

Within functions, you may want to double check that you aren'tare not referencing something that is not valid (iei.e.: null) and that array lengths are valid before referencing elements with indexes on all temporary/local instantiations. A good heuristic is to not trust the libraries you didn'tdid not write either. So any time you call them, check what you get back from them. It often helps to create a small library of "asserting" and "checking" functions to do this along with a logger so you can trace your path and reduce the need for extensive debugging cycles in the first place. With the advent of logging libraries and aspect oriented programming, many of the tedious aspects (yes, a pun) of defensive programming are mitigated.

Generally speaking then, it is preferrable to throw intelligible exception messages that enforce part of your API contract and guide the client programmer instead of returning values that a client programmer is likely to be unprepared for and hence minimize their complaints and increase robustness and security of your software.