|
Sources of Errors
To create an error handling strategy, we should fi rst analyze where errors can
happen. Errors can happen on every call to the database, and although this is
rather unlikely, we will look at this scenario. But before doing so, let's
check each of the possible error sources and defi ne a strategy for dealing
with them.
Server Software Failure or Overload
This can happen on a really busy server, which cannot handle any more incoming
connections. For example, there may be a lengthy update running in the
background. The outcome is that we are unable to get any data from the
database, so we should do the following.
If the PDO constructor fails, we present a page displaying a message, which says
that the user's request could not be fulfi lled at this time and that they
should try again later. Of course, we should also log this error because it may
require immediate attention. (A good idea would be emailing the database
administrator about the error.)
|
Chapter Contents
This excerpt from Chapter NO. 3 "Error Handling"
from Learning
PHP Data Objects by Dennis Popel, is printed with permission
from Packt Publishing, Copyright
2007.
|
|
If the PDO constructor fails, we present a page displaying a message, which says
that the user's request could not be fulfi lled at this time and that they
should try again later. Of course, we should also log this error because it may
require immediate attention. (A good idea would be emailing the database
administrator about the error.)
Improper Configuration of the Application
This error can only occur when we move the application across servers where
database access details differ; this may be when we are uploading from a
development server to production server, where database setups differ. This is
not an error that can happen during normal execution of the application, but
care should be taken while uploading as this may interrupt the site's
operation.
If this error occurs, we can display another error message like: "This site is
under maintenance". In this scenario, the site maintainer should react
immediately, as without correcting, the connection string the application
cannot normally operate.
|
Improper Validation of User Input
This is an error which is closely related to SQL injection vulnerability. Every
developer of database-driven applications must undertake proper measures to
validate and fi lter all user inputs. This error may lead to two major
consequences: Either the query will fail due to malformed SQL (so that nothing
particularly bad happens), or an SQL injection may occur and application
security may be compromised. While their consequences differ, both these
problems can be prevented in the same way.
Let's consider the following scenario. We accept some numeric value from a form
and insert it into the database. To keep our example simple, assume that we
want to update a book's year of publication. To achieve this, we can create a
form that has two fi elds: A hidden fi eld containing the book's ID, and a text
fi eld to enter the year. We will skip implementation details here, and see how
using a poorly designed script to process this form could lead to errors and
put the whole system at risk.
The form processing script will examine two request variables:
$_REQUEST['book'], which holds the book's ID and $_REQUEST['year'], which holds
the year of publication. If there is no validation of these values, the fi nal
code will look similar to this:
$book = $_REQUEST['book'];
$year = $_REQUEST['year'];
$sql = "UPDATE books SET year=$year WHERE id=$book";
$conn->query($sql);
Let's see what happens if the user leaves the book fi eld empty. The fi nal SQL
would then look like:
UPDATE books SET year= WHERE id=1;
This SQL is malformed and will lead to a syntax error. Therefore, we should
ensure that both variables are holding numeric values. If they don't, we should
redisplay the form with an error message.
Now, let's see how an attacker might exploit this to delete the contents of the
entire table. To achieve this, they could just enter the following into the
year field:
2007; DELETE FROM books;
This turns a single query into three queries:
UPDATE books SET year=2007; DELETE FROM books; WHERE book=1;
Of course, the third query is malformed, but the fi rst and second will execute,
and the database server will report an error. To counter this problem, we could
use simple validation to ensure that the year fi eld contains four digits.
However, if we have text fi elds, which can contain arbitrary characters, the
fi eld's values must be escaped prior to creating the SQL.
Inserting a Record with a Duplicate Primary Key or Unique Index Value
This problem may happen when the application is inserting a record with
duplicate values for the primary key or a unique index. For example, in our
database of authors and books, we might want to prevent the user from entering
the same book twice by mistake. To do this, we can create a unique index of the
ISBN column of the books table. As every book has a unique ISBN, any attempt to
insert the same ISBN will generate an error. We can trap this error and react
accordingly, by displaying an error message asking the user to correct the ISBN
or cancel its addition.
Syntax Errors in SQL Statements
This error may occur if we haven't properly tested the application. A good
application must not contain these errors, and it is the responsibility of the
development team to test every possible situation and check that every SQL
statement performs without syntax errors.
If this type of an error occurs, then we trap it with exceptions and display a
fatal error message. The developers must correct the situation at once.
Now that we have learned a bit about possible sources of errors, let's examine
how PDO handles errors.
Page
1 | page
2 | page
3
|
