Content deleted Content added
edited/added hyperlinks |
|||
Line 5:
'''Defensive programming''' is a form of [[defensive design]] intended to ensure the continuing function of a piece of [[software]] under unforeseen circumstances. Defensive programming practices are often used where [[high availability]], [[safety]], or [[computer security|security]] is needed.
Defensive programming is an approach to improve software and [[source code]], in terms of:
* General quality – reducing the number of [[software bug]]s and problems.
* Making the
* Making the software behave in a predictable manner despite unexpected inputs or user actions.
Line 49:
{{main|Offensive programming}}
Offensive programming is a category of defensive programming, with the added emphasis that certain errors should ''not'' be [[graceful degradation|handled defensively]]. In this practice, only errors from outside the program's control are to be handled (such as user input); the software itself, as well as data from within the program's line of defense, are to be trusted in this [[methodology]].
=== Trusting internal data validity ===
Line 134:
* 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 (computer programming)|string]] data in [[C (programming language)|C]]. C library functions like <tt>gets</tt> should never be used since the maximum size of the input buffer is not passed as an argument. C library functions like <tt>scanf</tt> can be used safely, but require the programmer to take care with the selection of safe format strings, by sanitizing it before using it.
* Encrypt/authenticate all important data transmitted over networks. Do not attempt to implement your own encryption scheme, but use a proven one instead.
* All [[data]] is important until proven otherwise.
* All data is tainted until proven otherwise.
* All code is insecure until proven otherwise.
| |||