SQL Injection Attacks and Defense - 2009

332 Chapter 7 • Advanced Topics
At this point, your attack is successful and the application’s query is subverted. The name
retrieved from the database is handled unsafely, and you are able to break out of the data
context within the query and modify the query’s structure. In this proof-of-concept attack,
the database version string is copied into the name of your contact, and will be displayed
on-screen when you view the updated contact details:
Name: aMicrosoft SQL Server 7.00 – 7.00.623 (Intel X86) Nov 27 1998
22:20:07 Copyright (c) 1988–1998 Microsoft Corporation Desktop
Edition on Windows NT 5.1 (Build 2600: )a
Address: 52 Throwley Way
To perform a more effective attack, you would need to use the general techniques
already described for injecting into UPDATE statements (see Chapter 8), again placing your
attacks into one contact field and then updating a different field to trigger the vulnerability.
Finding Second-Order Vulnerabilities
Second-order SQL injection is more difficult to detect than first-order vulnerabilities, because
your exploit is submitted in one request and executed in the application’s handling of a
different request. The core technique for discovering most input-based vulnerabilities, where
an individual request is submitted repeatedly with various crafted inputs and the application’s
responses are monitored for anomalies, is not effective in this instance. Rather, you need to
submit your crafted input in one request, and then step through all other application functions
which may make use of that input, looking for anomalies. In some cases, there is only one
instance of the relevant input (e.g., the user’s display name), and testing each payload may
necessitate stepping through the application’s entire functionality.
Today’s automated scanners are not very effective at discovering second-order SQL
injection. They typically submit each request numerous times with different inputs, and
monitor the responses. If they then crawl other areas of the application and encounter
database error messages, they will draw them to your attention, hopefully enabling you to
investigate and diagnose the issue. But they are not capable of associating an error message
returned in one location with a piece of crafted input submitted in another. In some cases,
there is no error message, and the effects of the second-order condition may be handled
blindly. If there is only a single instance of the relevant persisted item, or persisting it
within the application requires multiple steps (e.g., a user registration process), the problem
is compounded further. Hence, today’s scanners are not able to perform a rigorous
methodology for discovering second-order vulnerabilities.
Without an understanding of the meaning and usage of data items within the application,
the work involved in detecting second-order SQL injection grows exponentially with the size
of the application’s functionality. But human testers can use their understanding of that functionality,
and their intuition about where mistakes are often made, to reduce the size of the task.
In most cases, you can use the following methodology to identify second-order vulnerabilities: