Application Security - Implementing Database Security and Auditing - page 158

application code creates vulnerabilities, then it really shouldn't be com-
pletely trusted.
The first implementation option is to remove the application vulnerabil-
ities. This is normally the responsibility of the application owner, but some-
times it is appropriate for you as the database owner to be involved. By now
there are some good SQL injection guidelines for application developers,
such as the following:
All data entered by users needs to be sanitized of any characters or
strings that should not be part of the input expression, and all input
field must be validated.
SQL used to access the database from application code should never
be formed using string concatenation.
Strongly typed parameters (usually in combination with stored proce-
dures) should be used wherever possible.
Prepared statements, parameter collections, and parameterized stored
procedures should be used wherever possible.
Application login should be a function implemented within a well-
validated stored procedure.
Quotes should be added to all user input, even to numeric data.
These guidelines are for developers. If you have some leverage, use it.
Make developers adhere to these guidelines. If you are fortunate, you can
even require a code review in which you participate; in this case try to look at
the framework for managing the SQL that hits the database (hopefully there
is a framework and it's not just string concatenation all over the place).
I want to stress the use of prepared statements. When you use prepared
statements as opposed to string concatenation, the SQL strings are distinct
from the values that you get from the user, and thus there is no mixing of
SQL and parameters. This is therefore one of the simplest ways to combat
SQL injection. Monitoring and tracking whether prepared statements are
used is actually simple to do. If you use a network-based SQL inspection
product, you will see a difference in the SQL that travels on the network in
the case of prepared statements, and you can easily look at all of the SQL
traffic generated by an application to make sure that only prepared state-
ments are used. With prepared statements, the SQL (in this case for Oracle)
will look like: