SQL Injection Attacks and Defense - 2009

Use Strong Cryptography
to Protect Stored Sensitive Data
Platform-Level Defenses • Chapter 9 397
A key mitigating control against unauthorized viewing of sensitive data in the database is
the use of strong cryptography. The options include storing a mathematical hash of the data
(rather than the data itself) or storing the data encrypted with a symmetric algorithm. In both
cases, you should use only public algorithms deemed cryptographically strong. You should
avoid homegrown cryptographic solutions at all costs.
If the data itself does not require storage, consider an appropriately derived mathematical
hash instead. An example of this is data used for challenging the identity of a user, such as
passwords or security question answers. If an attacker is able to view the table storing this
data, only password hashes will be returned. The attacker must go through the time-consuming
exercise of cracking password hashes to obtain the actual credentials. Another clear benefit to
hashing is that it eliminates the key management issues associated with encryption. To stay
consistent with security best practices, ensure that the hashing algorithm of choice has not
been determined mathematically susceptible to collisions, such as MD5 and SHA-1. Consult
resources such as NIST (http://csrc.nist.gov/groups/ST/hash/policy.html) to find out the
current set of hashing algorithms deemed acceptable for use by federal agencies.
If you must store sensitive data, protect it with a strong symmetric encryption algorithm
such as Advanced Encryption Standard (AES) or Triple DES (Data Encryption Standard).
The primary challenge to encrypting sensitive data is storing the key in a location that the
attacker cannot access easily. You should never store encryption keys client-side, and the best
server-side solution for key storage usually depends on the application architecture. If the
key can be provided at runtime, this is ideal as it will only reside in memory on the server
(and depending on the application framework it can be possible to protect it while in
memory). However, on-the-fly key generation is usually not feasible or practical in most
enterprise application environments. One possible solution is to store the key in a protected
location on the application server so that the attacker needs to compromise both the database
server and the application server to decrypt it. In a Windows environment, you can use the
Data Protection API (DPAPI) to encrypt application data and leverage the operating system
to securely store the key. Another Windows-specific option is storing the key in the
Windows Registry, which is a more complex storage format than a flat text file and therefore
could be more challenging to view depending on the level of unauthorized access gained by
the attacker. When operating system specific storage options are not available (such as with
a Linux server), you should store the key (or secret used to derive it) on a protected area of
the file system with strict file system ACLs applied. It’s also worth noting that as of Microsoft
SQL Server 2005 and Oracle Database 10g Release 2, both support column-level encryption
natively. However, these nice built-in features do not provide much additional protection
against SQL injection, as this information will usually be transparently decrypted for the
application.