Defensive programming: Difference between revisions

Revision as of 11:27, 4 April 2025

Latest revision as of 21:09, 30 July 2025

(2 intermediate revisions by 2 users not shown)

Line 1:

{{Short description|Software development methodology}}

{{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 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 |language=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:

Line 15:

{{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) {

Line 120:

* [[Legacy code]] may not have been designed under a defensive programming initiative, and might therefore be of much lower quality than newly designed source code.

* Legacy code may have been written and tested under conditions which no longer apply. The old quality assurance tests may have no validity any more.

** '''Example 1''': legacy code may have been designed for ASCII input but now the input is [[UTF-8]].

** '''Example 2''': legacy code may have been compiled and tested on 32-bit architectures, but when compiled on 64-bit architectures, new arithmetic problems may occur (e.g., invalid signedness tests, invalid type casts, etc.).

** '''Example 3''': legacy code may have been targeted for offline machines, but becomes vulnerable once network connectivity is added.

Line 126:

Notable examples of the legacy problem:

* [[BIND|BIND 9]], presented by Paul Vixie and David Conrad as "BINDv9 is a [[Rewrite (programming)|complete rewrite]]", "Security was a key consideration in design",<ref>{{Cite web|url=http://impressive.net/archives/fogo/[e-mail]|title=fogo archive: Paul Vixie and David Conrad on BINDv9 and Internet Security by Gerald Oskoboiny <[e-mail]>|website=impressive.net|access-date=2018-10-27}}</ref> naming security, robustness, scalability and new protocols as key concerns for rewriting old legacy code.

* [[Microsoft Windows]] suffered from "the" [[Windows Metafile vulnerability]] and other exploits related to the WMF format. Microsoft Security Response Center describes the WMF-features as ''"Around 1990, WMF support was added... This was a different time in the security landscape... were all completely trusted"'',<ref>{{Cite news|url=http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx|title=Looking at the WMF issue, how did it get there?|work=MSRC|access-date=2018-10-27|language=en-US|archive-url=https://web.archive.org/web/20060324152626/http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx|archive-date=2006-03-24|url-status=dead}}</ref> not being developed under the security initiatives at Microsoft.

* [[Oracle Corporation|Oracle]] is combating legacy problems, such as old source code written without addressing concerns of [[SQL injection]] and [[privilege escalation]], resulting in many security vulnerabilities which have taken time to fix and also generated incomplete fixes. This has given rise to heavy criticism from security experts such as [[David Litchfield]], [[Alexander Kornbrust]], [[Cesar Cerrudo]].<ref>{{Cite web|url=http://seclists.org/lists/bugtraq/2006/May/0039.html|title=Bugtraq: Oracle, where are the patches???|last=Litchfield|first=David|website=seclists.org|access-date=2018-10-27}}</ref><ref>{{Cite web|url=http://seclists.org/lists/bugtraq/2006/May/0045.html|title=Bugtraq: RE: Oracle, where are the patches???|last=Alexander|first=Kornbrust|website=seclists.org|access-date=2018-10-27}}</ref><ref>{{Cite web|url=http://seclists.org/lists/bugtraq/2006/May/0083.html|title=Bugtraq: Re: [Full-disclosure] RE: Oracle, where are the patches???|last=Cerrudo|first=Cesar|website=seclists.org|access-date=2018-10-27}}</ref> An additional criticism is that default installations (largely a legacy from old versions) are not aligned with their own security recommendations, such as [[Oracle Database]] Security Checklist, which is hard to amend as many applications require the less secure legacy settings to function correctly.

=== Canonicalization ===

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