SQL Injection Attacks and Defense - 2009

Advanced Topics • Chapter 7 333
1. After you have mapped out the application’s content and functionality, review it,
looking for any items of user-controllable data that are persisted by the application
and reused in subsequent functions. Work on each item individually, and perform
the following steps on each instance.
2. Submit a simple value within the item that is likely to cause problems if used
unsafely in an SQL query, such as a single quote or an alphanumeric string
with a single quote within it. If required, walk through any multistage processes
(such as user registration) to ensure that your value is fully persisted within the
application.
3. If you find that the application’s input filters block your input, use the techniques
described earlier in this chapter (in “Evading Input Filters”) to try to defeat the
front-end input filters.
4. Walk through all of the application’s functionality where you have seen the data
item being explicitly used, and also any functions where it might conceivably be
implicitly used. Look for any anomalous behavior that may indicate that the input
has caused a problem, such as database error messages, HTTP 500 status codes,
more cryptic error messages, broken functionality, missing or corrupted data, and
so forth.
5. For each potential issue identified, try to develop a proof-of-concept attack to
verify that an SQL injection vulnerability is present. Be aware that malformed
persisted data may cause anomalous conditions in ways that are not directly
vulnerable (e.g., integer conversion errors, or failure of subsequent data validation).
Try supplying the same input with two quotation marks together, and see
whether the anomaly goes away. Try using database-specific constructs such as
string concatenation functions and version banners to confirm that you are
modifying an SQL query. If the anomalous condition is blind (i.e., it does not
return the results of the query or any error message), try using time delay techniques
to verify that a vulnerability is present.
You should be aware that some second-order SQL injection vulnerabilities are fully
blind and have no discernible effects on the contents of any application responses.
For example, if an application function writes persisted data to logs in an unsafe manner,
and handles any exceptions gracefully, the steps I just described will probably miss the
vulnerability. To detect these kinds of flaws, you need to repeat the preceding steps using
various inputs in step 1 designed to trigger time delays when used unsafely in SQL
queries, and then monitor all of the application’s functionality for anomalous delays.
To do this effectively, you will need to use syntax that is specific to the type of database
being used and the types of queries (SELECT, INSERT, etc.) being performed. In practice,
this may be a very lengthy exercise indeed.