D E F E N S I V E S O FT W A R E C O D I NG
I n t r o du c t i o n
Software coding is the process of transforming computer
instructions into a form a computer can understand. Every
software project operates because programmers write code.
Security of codes and software project from unforeseen
circumstances and accidental security breaches has been a major
treat to software development hence, the reason for defensive
software coding.
Defensive Software Coding
Defensive software (coding) or Programming is the process of
designing and implementing software so that it continues to
function even when under attack. Software written using this
process is able to detect erroneous conditions resulting from
some attack, and to either continue executing safely, or to fail
gracefully. The key rule in defensive programming is to never
assume anything, but to check all assumptions and to handle any
possible error states.
This definition emphasizes the need to make explicit any
assumptions about how a program will run, and the types of input
it will process.
Again, defensive programming means that the programmer must
carefully check any assumptions made, check and handle all
possible errors, and carefully check any interactions with existing
code. Failure to identify and manage such interactions can result
in incorrect program behaviour and the introduction of
vulnerabilities into a previously secure program.
Defensive software coding is a form of defensive design
intended to develop programs that are capable of detecting
potential security abnormalities and make predetermined
responses.
It is the practice of developing computer software in such a
way that guards against the accidental introduction of
security vulnerabilities in the form of defects, bugs and
logic flaws.
Through the analysis of thousands of reported
vulnerabilities, security professionals have discovered that
most vulnerabilities come from a relatively small number of
common software programming errors.
In all defensive coding practices are often used where high
availability, safety, or security is needed.
Its approach is to improve software/source code in terms
of :
General Quality
Making the source code comprehensible
Making the software behave in a predictable manner
Categories includes:
Secure programming: this emphasizes the development
of highly secure programs. Sees software as can fail in
certain ways as long as it is secure from any malicious
exploitation attempts
Offensive programming: its approach is that errors that
should be handled defensively should come from
outside the applications, such as user input.
C o d i n g S t a n d a r ds a n d G u i d e l i n e s
The main goal of the coding phase is to code from the
design document prepared after the design phase through
the high-level language and then to unit testing of this code.
Each organization usually makes their own coding
standards and guidelines depending on what suits them.
Purpose of having coding standards:
○ Coding standard gives a uniform appearance
○ It improves readability, maintainability and reduces
complexity
○ It helps in code reuse and helps to detect error easily
○ It promotes sound programming practices
So m e o f t h e c o d i ng s t and ar d s ar e :
○ Limit the use of global(s)
○ Standard headers for different modules
○ Naming conventions for local or global variables,
constants & functions
○ Indentation
○ Error return values and exception handling conventions
○ Avoid using a coding style that is too difficult to
understand
○ Avoid using an identifier for multiple purposes
○ Code should be well documented
○ Length of functions should not be very large
○ Try not to use Unconditional statement e.g. GOTO
statement
C o d e R e vi e w , W al k t h r o ug h & I ns pe ct i o n
C o d e r e vi e w:
○ This is carried out after a module is successfully
compiled.
○ It is an extremely cost-effective strategy for reduction
of errors and to produce high quality code.
There are two types of code reviews techniques:
○ Code walkthrough
○ Code inspection
C o de w alk t hr o u gh
○ This is an informal code analysis technique
○ Members of the development team are given the code
few days
before the walk-through meeting to read and
understand the code.
○ Its main objective is to discover the algorithmic and
logical errors
in the code
C o de w alk t hr o u gh g uide lin e s :
Performing team is not is too big or small (consists of 3
– 7 members)
Focus is on discovery of errors and not on how to fix the
discovered errors
Managers should not attend the walkthrough meetings.
● Code Inspection
The aim of code inspection is to discover some common
types of errors caused due to oversight and improper
programming
Some of the programming errors which can be checked are:
Use of uninitialized variables.
Jumps into loops.
Incompatible assignments.
Array indices out of bounds.
Use of incorrect logical operators or incorrect
precedence among operators.
Improper modification of loop variables.
The Software Assurance Forum for Excellence in Code (SAFE
Code), with a number of major IT industry companies as
members, develop publications outlining industry best practices
for software assurance and providing practical advice for
implementing proven methods for secure programming, including.
1. Input Validation and Data Sanitization
2. Input Size and Buffer Overflow
3. Interpretation of Program Input
4. Correct Handling of Exceptions and Unexpected
Behaviours
5. The list continues check out this link =➔
https://owasp.org/www-
pdfarchive/OWASP_SCP_Quick_Reference_Guide_v2.pdf
E x a m p l e s o f C r i t i ca l S o f t wa r e Fa i l u r e
As software becomes increasingly important, the potential impact
of bad code will increase to match. Software defects have caused
a lot of devastating effects in the last few decades. Software
failure is very prevalent everywhere. Here are some examples of
cases of software failure: z
1. Ariane-5 Satellite Launcher: On June 4 1996, there was total
failure of Ariane-5 launcher on its maiden flight.
Approximately 40 seconds after takeoff, the Ariane-5 rocket
launcher was shut down and then lost control due to
software failure resulting from internal variable exceeding a
limit imposed by the underlying code which resulted in
buffer overflow. It was reported that incorrect control
signals were sent to the engines and these caused swivelled
which caused it to break up and self-destructed. The
software failed and the system and the backup system shut
down. Ironically, the code that failed was generating
information that was not even necessary as soon as the
launch had started.
2. The Therac-25: This is a radiation therapy machine used to
administer drug to patients. The machine administered
massive overdoses of the drug resulting in the death of
patients. This was caused by software upgrade. The
software upgrade allowed the operator to type faster when
entering data. The parts of the machine that were not
upgraded could not cope with the speed of data entry, thus
causing the machine to administer the wrong doses. It took
several weeks of intensive investigation to determine the
cause of the problem.
3. The US Navy Ship Yorktown: In 1997, a prototype US
Navy ship while trying to adjust a valve setting, a sailor
mistakenly entered a zero into a database field; the ship
was out of action for three hours. The fault was caused
by a software failure due to improper input (data) field
validation. The software program that the sailor was
using on Windows NT should have refused to accept his
command but did otherwise, and the program shut down
the system. This is an operator error. However, the
software was not properly designed. It should have been
designed to recognize and reject an illegal command by
throwing exception.
4. The Marines’ Osprey Crashes: In December 2000, the US
Marine Corps’ new hybrid plane-helicopter, known as the
V-22 Osprey, crashed, killing four marines. The accident
was largely due to software error.
5. US Telephone Networks Failure: In the summer of 1991,
telephone networks in several major United States cities
suffered failure. The problems were traced to telephone
switching software consisting of several million lines of code.
The potential losses were enormous.
6. The Bank of New York: On November 20, 1995, the bank of
New York’s securities transaction software had a storage
fault. For about ninety minutes, it lost information on $32
billion in transactions. The bank was forced to borrow $23.6
billion from the US Federal Reserve for a day, at a cost in
interest of $5 million. Although the information was later
recovered, the bank’s reputation suffered as customers
began to doubt the bank
7. US Patriot Air Defense Collided with Incoming Scud
Missile: In the 1991 Gulf War, 28 US troops lost their
lives when the Patriot air defense system collided with
an incoming Scud Missile. The problem was caused by
software error resulting from software upgrade. An
upgrade to deal with missile was made, but at one place
in the upgraded software, a necessary call to the
subroutine was accidentally omitted. Although, the
problem was detected, a warning was issued, and a
software patch dispatched to users more than a week
before the accident occurred. There was need to reboot
the engine occasionally to correct the error which would
have taken only one minute. There were warnings but
the battery managers refused to heed to the warnings.
8. And the list continues .......
https://file.scirp.org/pdf/JCC_2014042514514136.pdf
C W E T O P 2 5 M o s t D a n g e r o u s C o di n g E r r o r s
Common Weakness Enumeration (CWE™) is a community-
developed list of software and hardware weakness types. It
serves as a common language, a measuring stick for security
tools, and as a baseline for weakness identification, mitigation,
and prevention efforts. The CWE listed 25 most Dangerous
Coding errors which can be found here:
i. https://www.sans.org/top25-software-errors/
ii. https://www.grazitti.com/blog/cwe-sans-top-25-
most-dangerous-programming-errors/
Open any of the links to see the list of 25 prevalent coding /
programming errors.
The solution to coding errors listed above is Defensive software
coding/ Programming.