Defensive design
Anticipating misuse
Defensive design is the practice of anticipating every possible way that an end-user could misuse a
system or device so that the number of errors/bugs is minimised. This means that the program will
behave as expected in spite of unexpected user actions. All possible errors are identified and allowed
for by writing the appropriate code to deal with them properly.
If the program crashes, behaves in an unintended fashion or the data security has been
compromised, then the defensive design has not been adequate.
For example, division by zero may crash a program.
Communication error – as online systems require connections to host servers, when this connection
is dropped, the program could potentially crash or hang when loading/saving data, so the
programmer should enable the user to cancel requests or to report connection errors so that the
program can resume when connection is available again
Disk errors – read to and write to programs need to handle many types of exceptions such as
file/folder not being found
disk being out of space
data in the file being corrupt
end of file being reached
robust programs will check files and data before attempting to use them for further processing
Printer/peripheral errors – if printer runs out of paper, ink or have a jam, the user must have the
option to reprint and not assume all are successful
Authentication
Authentication is a way of confirming that the user is authorised to access the system
The entered details of a username and password are checked against a database containing valid
accounts
Two – factor authentication – sending an SMS text to the designated mobile phone
Biometric – fingerprint, face id, optical sent off to a database and checked against their valid data
Including encryption within the application helps with data security, password set is encrypted
before being stored in a database/file
Authentication is not foolproof – could be identity theft
authentication – if you want to recover a password click on a link within an email sent to the
registered address
online bots can submit data automatically to online forms and this is protected by reCAPTCHA which
verifies that the user is human
SQL injection hacks and other hacking methods should also be aware to programmers
,User Interface
To choose the right interface you must consider balancing the access given to users on all the
information and abilities they might need, as well as imposing limits on the things they commonly
get wrong.
Menu Driven Interface limits the user to being able to pick from a displayed list of choices. This helps
to limit unexpected or invalid entries. However, this is not very flexible.
Screen widgets
The calendar widget – pops up a calendar from which the user can select a date so the programmer
is able to pick from a variety of choices and they cannot select an invalid or erroneous date
Colour picker widget – this does contain a number of input boxes so it is possible for the user to get
things wrong
Drop down lists – number of items the user is allowed to select, the numeric data entry will always
be valid
Text entry
Most flexible way of accepting inputs from the user – but also the most problematic
The programmer should inform the user with clear unambiguous instructions on screen of what they
need to enter
Also the option to re-enter passwords to ensure that the initial password is what the user intended
to write
The input box
It is the most vulnerable to problems. Defensive measures used in input boxes are known as
validation.
Input validation
Validation seeks to ensure that data entered is valid for further processing by the program handling
it by checking it against specific criteria. This ensures that the program will not crash if the user
enters an unreasonable or incorrect value
Validation only checks if data item is reasonable, not show if it is correct
Verification double checks that the data has been typed in correctly- data is entered twice and
compared in verification
Four validation methods:
Checking and limiting length of data
Checking the range of data
Checking the type of data
Checking the format of data
Length
, Rejecting entries that are too long or too short
Default instruction inside the box which disappears when an entry is made
If validation rule is broken:
Inform the user of the problem and allow them to re-enter the data
Truncate excess characters
Range
Inputs have to fall within certain values
Defensive design – write software code to check conditions are met
Type
Input conforms to the allowed data types
Software must be coded to deal with inputs without causing program error
Format
Code in the program will examine input and check that it fits the pattern correctly
Presence
data must be entered, Rejecting entries with nothing in them
Input validation techniques ensure that programs are:
More robust
More user friendly
Prevent further errors occurring later in the algorithm
validation process checks that data inputs are sensible, reasonable and appropriate
Deny list and allow list
An allow list is a list of data that the application will accept as valid
A deny list is a list of data that the application will reject
Often used with firewall applications and email filtering applications
A firewall is an application that helps protect a network from intrusion or to limit what the network
users can access online
It checks the URL sent from a web browser – which is effectively an input to the firewall application.
Should the firewall reject the URL because it is on the deny list, a notification will pop up
Much easier to create an allow list than a deny list – much easier to define what is acceptable rather
than trying to anticipate what isn’t acceptable
Debugging
Spotting and correcting mistakes – debugging
You must understand what the code is meant to be doing before you can correct it