Defensive programming: Difference between revisions

Revision as of 15:51, 25 February 2002

Revision as of 20:24, 26 February 2002

Line 1:

SomeHere hintsare howsome shouldhints youon codecoding to avoid security problems.

Many of these techniques also improve general quality of code., because almost any major bug can be potentially used by a [[cracker]]

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

That's because almost any major bug can be potentially used by a [[cracker]]

in [[Denial of Service]] or other attack.

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

One of the the most common problems is usageunchecked use of constant-size structures and functions

for dynamic-size data (the [[buffer overflow]] problem). This is especially usual problemscommon for [[string]] data in [[C]].

You should never use functions like <tt>sprintfgets</tt> and <tt>strcpyscanf</tt>.

Never make your code more complex thatthan necessary. Complexity isbreeds verybugs, commonincluding sourcesecurity of bugs,problems.

including security problems.

Either leave your code available to everyone on the Net (see [[Free software]])

Line 27 ⟶ 25:

If you check data for correctness, check if it's correct, not if it is incorrect.

CrackerCrackers are likely to invent new kinds of incorectincorrect data. For example, if

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

name of this file, like "/etc/../etc/passwd".