Defensive programming: Difference between revisions

Revision as of 08:57, 12 November 2021

Revision as of 09:30, 12 November 2021

Line 142:

Assume that code constructs that appear to be problem prone (similar to known vulnerabilities, etc.) are bugs and potential security flaws. The basic rule of thumb is: "I'm not aware of all types of [[security exploit]]s. I must protect against those I ''do'' know of and then I must be proactive!".

===Other techniquesTips to Secure Your Code===

* One of the most common problems is unchecked use of constant-size structuresor andpre-allocated functionsstructures for dynamic-size data 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]]. 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.

<!-- Please expand this article. These random notes should be changed to a more coherent article. -->

* Encrypt/authenticate all important data transmitted over networks. Do not attempt to implement your own encryption scheme, but use a [[Cryptography standards|proven one]] instead. Message checking with [[CRC]] or similar technology will also help secure data sent over a network.

* 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 <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, but use a proven one instead.

====The 3 Rules of Data Security====

* All [[data]] is important until proven otherwise.

* All [[data]] is taintedimportant until proven otherwise.

* All codedata is insecuretainted until proven otherwise.

* All code is insecure until proven otherwise.

** You cannot prove the security of any code in [[userland (computing)|userland]], or, more canonicallycommonly known as: ''"never trust the client"''.

These three rules about data security describe how to handle any data, internally or externally sourced:

* If data is to be checked for correctness, verify that it is correct, not that it is incorrect.

'''All data is important until proven otherwise''' means that all data must be verified as garbage before being destroyed.

'''All data is tainted until proven otherwise''' means that all data must be handled in a way that does not expose the rest of the runtime environment without verifying integrity.

'''All code is insecure until proven otherwise''' while a slight misnomer, does a good job reminding us to never assume our code is secure as bugs or [[Undefined Behavior]] may expose the project or system to attacks such as common [[SQL injection]] attacks.

====More Information====

* If data is to be checked for correctness, verify that it is correct, not that it is incorrect.

* [[Design by contract]]

** Design by contract uses [[precondition]]s, [[postcondition]]s and [[Invariant (computer science)|invariants]] to ensure that provided data (and the state of the program as a whole) is sanitized. This allows code to document its assumptions and make them safely. This may involve checking arguments to a function or method for validity before executing the body of the function. After the body of a function, doing a check of state or other held data, and the return value before exits (break/return/throw/error code), is also wise.

* [[Assertion (computing)|Assertions]] (also called '''assertive programming''')

** Within functions, you may want to check that you are not referencing something that is not valid (i.e., null) and that array lengths are valid before referencing elements, especially on all temporary/local instantiations. A good heuristic is to not trust the libraries you did not write either. So any time you call them, check what you get back from them. It often helps to create a small library of "asserting" and "checking" functions to do this along with a logger so you can trace your path and reduce the need for extensive [[debugging]] cycles in the first place. With the advent of logging libraries and [[aspect oriented programming]], many of the tedious aspects of defensive programming are mitigated.

* Prefer [[Exception handling|exceptions]] to return codes

** Generally speaking, it is preferable to throw intelligible exception messages that enforce part of your [[application programming interface|API]] [[Design by contract|contract]] and guide the client [[programmer]]developer instead of returning error code values that ado clientnot programmerpoint isto likelywhere tothe beexception unpreparedoccured foror andwhat hencethe minimizeprogram theirstack complaintslooked liked, Better logging and exception handling will increase robustness and security of your software., {{Dubious|date=Junewhile 2015}}minimizing developer stress.

==See also==