PHP and MySQL Web Development 4th Ed-tqw-_darksiderg

Security Threats
347
as ICMP. Detecting hosts on your network being used to attack others is easier than
protecting your machines from attack. If every network administrator could be relied on
to vigilantly monitor his own network, DDoS would not be such a problem.
Because there are so many possible methods of attack, the only really effective defense
is to monitor normal traffic behavior and have a pool of experts available to take countermeasures
when abnormal situations occur.
Errors in Software
Any software you have bought, obtained, or written may have serious errors in it. Given
the short development times normally allowed to web projects, the likelihood is high
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
unavailability, 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
A system’s designers and programmers need to make many assumptions. Of course, you
hope that they will document their assumptions and usually be right. Sometimes,
though, people make poor assumptions. For example, they might assume that input data
will be valid, will not include unusual characters, or will be less than a particular size.
They might also make 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
your developers did not consider that a person’s name might have an apostrophe in it.
These sorts of errors can be found and fixed with a combination of good testing and
detailed code review.
Historically, operating system or application-level weaknesses exploited by crackers
have usually related either to buffer overflows or race conditions.