Specifications

Errors in Software
It is possible that the software you have bought, obtained, or written has serious errors in it.
Given the short development times normally allowed to Web projects, it is highly likely that
this software has some errors. Any business that is highly reliant on computerized processes is
vulnerable to buggy software.
Errors in software can lead to all sorts of unpredictable behavior including service unavailabil-
ity, security breaches, financial losses, and poor service to customers.
Common causes of errors that you can look for include poor specifications, faulty assumptions
made by developers, and inadequate testing.
Poor Specifications
The more sparse or ambiguous your design documentation is, the more likely you are to end
up with errors in the final product. Although it might seem superfluous to you to specify that
when a customer’s credit card is declined, the order should not be sent to the customer, at least
one big-budget site had this bug. The less experience your developers have with the type of
system they are working on, the more precise your specification needs to be.
Assumptions Made by Developers
The designers and programmers of a system need to make many assumptions. Hopefully, they
will document their assumptions and usually be right. Sometimes though, people make poor
assumptions. These might include assumptions that input data will be valid, will not include
unusual characters, or will be less than a particular size. It could also include assumptions
about timing such as the likelihood of two conflicting actions occurring at the same time or
that a complex processing task will always take more time than a simple task.
Assumptions like these can slip through because they are usually true. A cracker could take
advantage of a buffer overrun because a programmer assumed a maximum length for input
data, or a legitimate user could get confusing error messages and leave because it did not occur
to your developers that a person’s name might have an apostrophe in it. These sort of errors
can be found and fixed with a combination of good testing and detailed code review.
Historically, the operating system or application level weaknesses exploited by crackers have
usually related either to buffer overflows or race conditions.
Poor Testing
It is rarely possible to test for all possible input conditions, on all possible types of hardware,
running all possible operating systems with all possible user settings. This is even more true
than usual with Web-based systems.
E-commerce and Security
P
ART III
288
17 7842 CH13 3/6/01 3:36 PM Page 288