Defensive programming

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 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.

---

Please expand this article. These random notes should be changed to a more coherent article.

• One of the 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.

You should never use functions like gets and scanf.

• 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 hire someone who will do security audit[?] for you.

• If possible, reuse code instead of writing from scratch.
• Encrypt all important data that flows the Net.
• All data is important until proved otherwise.
• All code is unsecure until proven otherwise.
• Never make your program setuid[?] unless you're really sure it's secure.
• If you check data for correctness, check 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 name of this file, like "/etc/../etc/passwd".

---

Books:

• William R. Cheswick and Steven M. Bellovin, Firewalls and Internet Security: Repelling the Wily Hacker ISBN 0201633574 http://www.wilyhacker.com/

External references:

• http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index