SQL Injection Attacks and Defense - 2009

Code-Level Defenses • Chapter 8 367
Damage & Defense…
SQL Injection in Stored Procedures
It is often assumed that SQL injection can happen only at the application level—for
example, in a Web application. This is incorrect, as SQL injection can occur at any level
where dynamic SQL is used, including at the database level. If unsanitized user input
is submitted to the database—for example, as a parameter to a stored procedure—
and then it is used in dynamic SQL, SQL injection can occur at the database level as
easily as at any other level.
Therefore, you should be careful when handling untrusted input at the database
level, and you should avoid dynamic SQL wherever possible. In situations where stored
procedures are in use, the use of dynamic SQL can often indicate that additional
procedures should be defined at the database level to encapsulate missing logic,
therefore enabling you to avoid the use of dynamic SQL within the database at all.
Using Abstraction Layers
When designing an enterprise application it is a common practice to define various layers
for presentation, business logic, and data access, allowing the implementation of each layer
to be abstracted from the overall design. Depending on the technology in use, this may
involve an additional data access abstraction layer such as Hibernate, or the use of a database
access framework such as ADO.NET, JDBC, or PDO. These layers of abstraction can be a
very useful place for the security-aware designer to enforce safe data access practices that
will then be used throughout the rest of the architecture.
A good example of this would be a data access layer that ensures that all database
calls are performed through the use of parameterized statements. Examples of using
parameterized statements in a number of technologies (including those mentioned earlier)
are provided in “Using Parameterized Statements” earlier in this chapter. Providing that the
application did not access the database in any way other than the data access layer, and that
the application did not then use the supplied information in dynamic SQL at the database
level itself, SQL injection is unlikely to be present. Even more powerful would be to
combine this method of accessing the database with the use of stored procedures, as this
would mitigate the risk even further. This may also have the effect of easing implementation,
as in that case all of the methods of accessing the database will have been defined, and would
therefore be easier to implement in a well-designed data access layer.