The SQL Injection Attack

Whenever data from the user are used to modify an SQL statement, an SQL injection attack 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 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

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 29th, 2011, the Lizamoon attack struck and affected over 1.5 million URLs (for more information see www.itproportal.com/2011/04/04/ lizamoon-attack-less-victims-than-feared/ )!

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 functions 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 users 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 nonvolatile—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

Part 4 Multiuser Database Processing

same configuration they were in at the time of the failure. Two other approaches are possible: recovery via reprocessing and recovery via rollback/rollforward.

The SQL Injection Attack