Content deleted Content added
→Other ways of securing code: !howto Tags: Mobile edit Mobile web edit Advanced mobile edit |
BrainStack (talk | contribs) Link suggestions feature: 3 links added. |
||
| (5 intermediate revisions by 5 users not shown) | |||
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 62:
}
return "black"; // To be handled as a dead traffic light.
}
</syntaxhighlight>
Line 77 ⟶ 74:
}
assert(0); // Assert that this section is unreachable.
}
</syntaxhighlight>
Line 126 ⟶ 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 132 ⟶ 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/20001005080818.O15286@impressive.net|title=fogo archive: Paul Vixie and David Conrad on BINDv9 and Internet Security by Gerald Oskoboiny
* [[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 144 ⟶ 138:
===Other ways of securing code===
* One of the most common problems is unchecked use of constant-size or pre-allocated structures for dynamic-size data{{cn|date=December 2023}} such as inputs to the program (the [[buffer overflow]] problem). This is especially common for [[string (computer programming)|string]] data in [[C (programming language)|C]]{{cn|date=December 2023}}. C library functions like <code>gets</code> should never be used since the maximum size of the input buffer is not passed as an argument. C library functions like <code>scanf</code> 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, use a [[Cryptography standards|proven one]] instead. Message checking with
====The three rules of data security====
| |||