Managing Multiuser Databases - Database Processing: Fundamentals, Design, and Implementation - page 415

Many other possibilities exist for extending DBMS security with application processing. In
general, however, you should use the DBMS security features first. Only if they are inadequate
for the requirements should you add to them with application code. The closer the security
enforcement is to the data, the less chance there is for infiltration. Also, using the DBMS
security features is faster and cheaper and probably results in higher-quality results than
developing your own.

The SQL Injection Attack
Whenever data from the user are used to modify an SQL statement, an SQL injection at-
tack is possible. For example, in the prior section, if the value of EmployeeName used in the
SELECT statement is not obtained via a secure means, such as from the operating system
rather than from a Web form, there is the chance that the user can inject SQL into the
statement.
For example, suppose that users are asked to enter their names into a Web form textbox.
Suppose that a user enters the value 'Benjamin Franklin' OR TRUE for his or her name. The SQL
statement generated by the application will then be the following:

/* *** EXAMPLE CODE - DO NOT RUN *** */
/* *** SQL-Code-Example-CH09-06 *** */
SELECT *

FROM EMPLOYEE

WHERE EMPLOYEE.Name = 'Benjamin Franklin' OR TRUE;

Of course, the value TRUE is true for every row, so every row of the EMPLOYEE table will be
returned! Thus, any time user input is used to modify an SQL statement, that input must be
carefully edited to ensure that only valid input has been received and that no additional SQL
syntax has been entered.
Despite being a well-known hacker attack, the SQL injection attack can still be very
effective if not defended against. On March 29, 2011, the Lizamoon attack struck and
affected more than 1.5 million URLs ( for more information, see http://en.wikipedia.org/wiki/
LizaMoon )!

Database Backup and Recovery

Computer systems fail. Hardware breaks. Programs have bugs. Human procedures contain
errors, and people make mistakes. All of these failures can and do occur in database applica-
tions. Because a database is shared by many people and because it often is a key element of
an organization's operations, it is important to recover it as soon as possible.
Several problems must be addressed. First, from a business standpoint, business func-
tions must continue. During the failure, customer orders, financial transactions, and packing
lists must be completed somehow, even manually. Later, when the database application is
operational again, the data from those activities must be entered into the database. Second,
computer operations personnel must restore the system to a usable state as quickly as possible
and as close as possible to what it was when the system crashed. Third, users must know what
to do when the system becomes available again. Some work may need to be reentered, and us-
ers must know how far back they need to go.
When failures occur, it is impossible simply to fix the problem and resume processing.
Even if no data are lost during a failure (which assumes that all types of memory are nonvol-
atile—an unrealistic assumption), the timing and scheduling of computer processing are too
complex to be accurately re-created. Enormous amounts of overhead data and processing
would be required for the operating system to be able to restart processing precisely where
it was interrupted. It is simply not possible to roll back the clock and put all of the electrons
in the same configuration they were in at the time of the failure. Two other approaches are
possible: recovery via reprocessing and recovery via rollback/rollforward .