SQL Injection Attacks and Defense - 2009

334 Chapter 7 • Advanced Topics
Tools & Traps…
Why Second-Order Bugs Happen
Second-order SQL injection is surprisingly common. The authors have encountered this
vulnerability in mature, security-critical applications such as those used by online
banks. Bugs such as this can go unnoticed for years, because of the relative difficulty
of detecting them.
Many, perhaps even most, developers these days have some awareness of SQL
injection threats, and they know how to use parameterized queries to safely incorporate
tainted data into SQL queries. However, they also know that writing parameterized
queries involves a little more effort than constructing simple dynamic queries. Many also
have in mind a mistaken concept of taint, in which user-supplied data needs to be
handled safely on arrival, but can then be treated as trusted.
A very common approach to coding SQL queries is to use parameterized queries
for data that is most obviously tainted, such as that which is received from the immediate
HTTP request, and elsewhere to make a judgment in each case as to whether the
data is safe to use in a dynamic query. This approach is dangerous. It can easily lead to
oversights, where tainted data is handled unsafely by mistake. Data sources that are
trustworthy may become tainted at a future time due to changes elsewhere in the
code base, unwittingly introducing second-order vulnerabilities. And the mistaken
concept of taint, where data needs to be handled safely only on arrival, can lead to
items appearing to be trustworthy when they are not.
The most robust way to defend against second-order vulnerabilities is to use
parameterized queries for all database access, and to properly parameterize every
variable data item which is incorporated into the query. This approach incurs a small
amount of superfluous effort for data which is genuinely trustworthy, but it will avoid
the mistakes described. Adopting this policy also makes security review of code quicker
and easier in relation to SQL injection.
Note that some parts of SQL queries, such as column and table names, cannot be
parameterized, because they constitute the structure which is fixed when the query is
defined, before data items are assigned to their placeholders. If you are incorporating
user-supplied data into these parts of the query, you should determine whether your
functionality can be implemented in a different way; for example, by passing index
numbers which are mapped to table and column names server-side. If this is not possible,
you should carefully validate the user data on a whitelist basis, prior to use.