Content deleted Content added
m Remove incorrect code comments, compilers will not remove default sections even if all possible enum values are covered. Compilers are not allowed to do this due to enums having more bit patterns than they have named members. A compilable example can be found here https://godbolt.org/z/hnKv7h8as |
BrainStack (talk | contribs) Link suggestions feature: 3 links added. |
||
| (4 intermediate revisions by 4 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 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/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 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====
| |||