Content deleted Content added
→Other ways of securing code: CRC not ggod for IDing accidental tamper |
No edit summary Tag: Reverted |
||
Line 1:
{{Short e Software Safety |date=2016-01-01 |url=https://www.sciencedirect.com/science/article/pii/B9781785481178500064 |work=Certifiable Software Applications 1 |pages=125–156 |editor-last=Boulanger |editor-first=Jean-Louis |publisher=Elsevier |languagdescription|Software development methodology}}
{{Use American English|date=November 2020}}
{{howto|date=March 2012}}
'''Defensive programming''' is a form of [[defensive design]] intended to develop programs that are capable of detecting potential security abnormalities and make predetermined responses.<ref>{{Citation |last=Boulanger |first=Jean-Louis |title=6 - Technique to Manage
Defensive programming is an approach to improve software and [[source code]], in terms of:
Line 169:
* [https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards CERT Secure Coding Standards]
'''Defensive programming''' is a form of [[defensive design]] intended to develop programs that are capable of detecting potential security abnormalities and make predetermined responses.<ref>{{Citation |last=Boulanger |first=Jean-Louis |title=6 - Technique to Manage=en |isbn=978-1-78548-117-8 |access-date=2022-09-02}}</ref> It ensures 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 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.
Overly defensive programming, however, may safeguard against errors that will never be encountered, thus incurring run-time and maintenance costs.
== Secure programming ==
{{main|Secure coding}}
Secure programming is the subset of defensive programming concerned with [[computer security]]. Security is the concern, not necessarily safety or availability (the [[software]] may be allowed to fail in certain ways). As with all kinds of defensive programming, avoiding bugs is a primary objective; however, the motivation is not as much to reduce the likelihood of failure in normal operation (as if safety were the concern), but to reduce the attack surface – the programmer must assume that the software might be misused actively to reveal bugs, and that bugs could be exploited maliciously.
<syntaxhighlight lang="c">int risky_programming(char *input) {
char str[1000];
// ...
strcpy(str, input); // Copy input.
// ...
}</syntaxhighlight>
The function will result in undefined behavior when the input is over 1000 characters. Some programmers may not feel that this is a problem, supposing that no user will enter such a long input. This particular bug demonstrates a vulnerability which enables [[buffer overflow]] [[exploit (computer security)|exploit]]s. Here is a solution to this example:
<syntaxhighlight lang="c">int secure_programming(char *input) {
char str[1000+1]; // One more for the null character.
// ...
// Copy input without exceeding the length of the destination.
strncpy(str, input, sizeof(str));
// If strlen(input) >= sizeof(str) then strncpy won't null terminate.
// We counter this by always setting the last character in the buffer to NUL,
// effectively cropping the string to the maximum length we can handle.
// One can also decide to explicitly abort the program if strlen(input) is
// too long.
str[sizeof(str) - 1] = '\0';
// ...
}</syntaxhighlight>
== Offensive programming ==
{{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
[[Category:Programming paradigms]]
[[Category:Programming principles]]
| |||