Justin Clarke Lead Author and Technical Editor Rodrigo Marcos Alvarez Dave Hartley Joseph Hemler Alexander Kornbrust Haroon Meer Gary O’Leary-Steele Alberto Revelli Marco Slaviero Dafydd Stuttard

User Data Sanitization
SQL injection vulnerabilities occur for two reasons:
Lack of user input sanitization
■
Data and control structures mixed in the same transport channel
■
These two issues together have been the cause of some of the most important 
types of vulnerabilities exploited so far in the history of computers, such as heap and 
stack overflows, and format string issues.
The lack of user input sanitization allows an attacker to 
jump
from the data part 
(e.g., a string enclosed between single quotes or a number) to inject control com-
mands (such as 
SELECT
, 
UNION
, 
AND
, 
OR
, etc.).
To defend against this type of vulnerability the first measure to adopt is to perform 
strict user input sanitization and/or output encoding. For example, you can adopt a 
whitelist approach, whereby if you are expecting a number as a parameter value, you can 
configure your Web application to reject every character from the user-supplied input 
which is not a digit. If you are expecting a string, you only accept characters that you 
previously determined are not hazardous. Where this is not possible, you must ensure 
that all input is correctly quoted/encoded prior to being used to prevent SQL injection.

---

 
Testing for SQL Injection • Chapter 2
 
39
In the following sections, you will see how the information reaches the database server 
and why the preceding errors where generated.
Information Workf low
In the previous section, you saw some SQL injection errors displayed as a result of parameter 
manipulation. You may be wondering why the Web server shows an error from the database 
if you modify a parameter. Although the errors are displayed in the Web server response, the 
SQL injection happens at the database layer. Those examples show how you can reach a 
database server via the Web application.
It is important to have a clear understanding of how your data entry influences an SQL 
query and what kind of response you could expect from the server. Figure 2.4 shows how 
the data sent from the browser is used in creating an SQL statement and how the results are 
returned back to the browser.
Figure 2.4 
Flow of Information in a Three-Tier Architecture
Figure 2.4 shows the information workflow between all parties normally involved in a 
dynamic Web request:
1. The user sends a request to the Web server.
2. The Web server retrieves user data, creates an SQL statement which contains the 
entry from the user, and then sends the query to the database server.
3. The database server executes the SQL query and returns the results to the
Web server. Note that the database server doesn’t know about the logic of the 
application; it will just execute a query and return results.
4. The Web server dynamically creates an HTML page based on the database response.

---