SQL Injection Attacks and Defense - 2009

Platform-Level Defenses • Chapter 9 395
more so than WAFs. Consider that the queries the Web application sends to the database
are, for the most part, a known quantity of commands, and their structure is known as
well. You can leverage this information to configure a highly tuned set of rules that takes
appropriate action (log, block, etc.) against unusual or malicious queries before ever hitting
the database. One of the hardest problems with locking down input in a WAF is that
malicious users can send in any combination of requests to the Web server. An example
open source implementation is GreenSQL, which you can download at www.greensql.net.
Securing the Database
When an attacker has an exploitable SQL injection vulnerability, he can take one of two
primary exploit paths. He can go after the application data itself, which depending on the
application and the data could be very lucrative. This is especially true if the application
handles and insecurely stores personally identifiable information or financial data, such as
bank account and credit card information. Alternatively, the attacker may be interested in
leveraging the database server to penetrate internal, trusted networks. In this section, we’re
going to look at ways to limit unauthorized access to application data. Then we’ll look at
some techniques for hardening the database server to help prevent privilege escalation and
limiting access to server resources outside the context of the target database server. You should
fully test the steps we’ll be covering in a non-production environment first, to avoid breaking
the functionality of existing applications. New applications have the benefit of building these
recommendations into the development life cycle early to avoid dependencies on unnecessary
and privileged functionality.
Locking Down the Application Data
Let’s first examine some techniques restricting the scope of an SQL injection attack to the
application database only. We’re also going to look at ways to restrict access even if the
attacker has been successfully sandboxed to the application database.
Use the Least-Privileged Database Login
Applications should connect to the database server in the context of a login that has permissions
for performing required application tasks only. This critical defense can significantly mitigate
the risk of SQL injection, by restricting what an attacker can access and execute when
exploiting the vulnerable application. For example, a Web application used for reporting purposes,
such as checking the performance of your investment portfolio, should ideally access the
database with a login that has inherited only the permissions on objects (stored procedures,
tables, etc.) needed to produce this data. This could be EXECUTE permissions on several
stored procedures and possibly SELECT permissions on a handful of table columns. In the
event of SQL injection, this would at least limit the possible set of commands to the stored
procedures and tables within the application database and prevent malicious SQL outside this