SQL Injection Attacks and Defense - 2009

366 Chapter 8 • Code-Level Defenses
SQL injection. Being at the design level, however, these techniques are more beneficial
to new development, as significantly rearchitecting an existing application to incorporate
different design techniques could require a great deal of effort.
Each design technique we’ll discuss in the subsections that follow can be implemented
in isolation; however, for best results it is recommended that you implement all of these
techniques together with the techniques outlined earlier in the chapter, where appropriate,
to provide true defense in depth against SQL injection vulnerabilities.
Using Stored Procedures
One design technique that can prevent or mitigate the impact of SQL injection is to design
the application to exclusively use stored procedures for accessing the database. Stored
procedures are programs stored within the database, and you can write them in a number of
different languages and variants depending on the database, such as SQL (PL/SQL for Oracle,
Transact-SQL for SQL Server, SQL:2003 standard for MySQL), Java (Oracle), or others.
Stored procedures can be very useful for mitigating the seriousness of a potential SQL
injection vulnerability, as it is possible to configure access controls at the database level when
using stored procedures on most databases. This is important, because it means that if an
exploitable SQL injection issue is found, the attacker should not be able to access sensitive
information within the database if the permissions are correctly configured.
This happens because dynamic SQL, due to its dynamic nature, requires more
permissions on the database than the application strictly needs. As dynamic SQL is assembled
at the application, or elsewhere in the database, and is then sent to the database for
execution, all data within the database that needs to be readable, writable, or updateable by
the application needs to be accessible to the database user account that is used to access the
database. Therefore, when an SQL injection issue occurs, the attacker can potentially access
all of the information within the database that is accessible to the application, as the attacker
will have the database permissions of the application.
With the use of stored procedures, you can change this situation. In this case, you would
create stored procedures to perform all of the database access the application needs.
The database user that the application uses to access the database is given permissions to
execute the stored procedures that the application needs, but does not have any other data
permissions within the database (i.e., the user account does not have SELECT, INSERT,
or UPDATE rights to any of the application’s data, but does have EXECUTE rights on the
stored procedures). The stored procedures then access the data with differing permissions—for
example, the permissions of the user who created the procedure rather than the user invoking
the procedure—and can interact with the application data as necessary. This can help you to
mitigate the impact of an SQL injection issue, as the attacker will be limited to calling the
stored procedures, therefore limiting the data the attacker can access or modify, and in many
cases preventing the attacker from accessing sensitive information in the database.