The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

The precise methods and syntax for creating parameterized queries

differ among databases and application development platforms. See Chapter 18

for more details about the most common examples.

If parameterized queries are to be an effective solution against SQL injec-

tion, then there are three important provisos to bear in mind:

■■

They should be used for every database query. The authors have

encountered many applications where the developers made a judgment

in each case whether or not to use a parameterized query. In cases

where user-supplied input was clearly being used, they did so; other-

wise, they didn’t bother. This approach has been the cause of many SQL

injection flaws. First, by focusing only on input that has been immedi-

ately received from the user, it is easy to overlook second-order attacks

because data that has already been processed is assumed to be trusted.

Second, it is easy to make mistakes about the specific cases in which the

data being handled is user-controllable. In a large application, different

items of data will be held within the session or received from the client.

Assumptions made by one developer may not be communicated to oth-

ers. The handling of specific data items may change in the future, intro-

ducing a SQL injection flaw into previously safe queries. It is much

safer to take the approach of mandating the use of parameterized

queries throughout the application.

■■

Every item of data inserted into the query should be properly parame-

terized. The authors have encountered numerous cases where most of a

query’s parameters are handled safely; however, one or two items are