SQL Injection Attacks and Defense - 2009

362 Chapter 8 • Code-Level Defenses
Damage & Defense…
Encoding from the Database
A common issue when using databases is the inherent trust of the data that is contained
in the database. Data contained within the database commonly is not subjected to
rigorous input validation or sanitization before being stored in the database; or, it may
have come from an external source—either from another application within the
organization or from a third-party source. An example behavior that can cause this is
the use of parameterized statements. Although parameterized statements are secure
in that they prevent exploitation of SQL injection by avoiding dynamic SQL, they are
often used instead of validating the input; as a result, the data stored within the
database can contain malicious input from the user. In these cases, you must be careful
when accessing the data in the database to avoid SQL injection and other types of
application security issues when the data is ultimately used or presented to the user.
One example of an issue that commonly occurs when unsafe data is present in
the database is XSS. However, SQL injection is also possible in this instance.
We discussed this topic in more depth from an attacker’s point of view in Chapter 7,
in “Exploiting Second-Order Injection.”
Therefore, you should always consider performing context-specific encoding on
the data you fetch from the database. Examples would include encoding for XSS issues
before presenting content to the user’s browser, as well as encoding for SQL injection
characters, as discussed in the previous section, before using database content in
dynamic SQL.
Canonicalization
A difficulty with input validation and output encoding is ensuring that the data being
evaluated or transformed is in the format that will be interpreted as intended by the end
user of that input. A common technique for evading input validation and output encoding
controls is to encode the input before it is sent to the application in such a way that it is
then decoded and interpreted to suit the attacker’s aims. For example, Table 8.6 lists
alternative ways to encode the single-quote character.