SQL Injection Attacks and Defense - 2009

368 Chapter 8 • Code-Level Defenses
Handling Sensitive Data
A final technique for mitigating the seriousness of SQL injection is to consider the storage
and access of sensitive information within the database. One of the goals of an attacker is to
gain access to the data that is held within the database—often because that data will have
some form of monetary value. Examples of the types of information an attacker may be
interested in obtaining may include usernames and passwords, personal information,
or financial information such as credit card details. Because of this, it is worth considering
additional controls over sensitive information. Some example controls or design decisions to
consider might be the following:
■■
■■
■■
Passwords Where possible, you should not store users’ passwords within the
database. A more secure alternative is to store a salted one-way hash (using a secure
hash algorithm such as SHA256) of each user’s password instead of the password
itself. The salt, which is an additional small piece of random data, should then
ideally be stored separately from the password hash. In this case, instead of
comparing a user’s password to the one in the database during the login process,
you would compare the salted hash calculated from the details supplied by the
user to the value stored in the database. Note that this will prevent the application
from being able to e-mail the user his password when he forgets it; in this case,
it would be necessary to generate a new, secure password for the user and provide
that to him instead.
Credit card and other financial information You should store details such as
credit cards encrypted with an approved (i.e., FIPS-certified) encryption algorithm.
This is a requirement of the Payment Card Industry Data Security Standards
(PCI-DSS) for credit card information. However, you should also consider
encrypting other financial information that may be in the application, such as
bank account details.
Archiving Where an application is not required to maintain a full history of all
of the sensitive information that is submitted to it (e.g., personally identifiable
information), you should consider archiving or removing the unneeded information
after a reasonable period of time. Where the application does not require this
information after initial processing, you should archive or remove unneeded
information immediately. In this case, removing information where the exposure
would be a major privacy breach may reduce the impact of any future security
breach by reducing the amount of customer information to which an attacker
can gain access.