Dave,
Your best bet will be to do unencryption in the application. The rationale behind this is that if your database is compromised by a SQL injection attack, all of the functions, sprocs, views and tables will be accessible by the attacker. Thus, the decrypt function in the database can be utilized by the attacker in compromising your data.
If a successful injection attack is executed against your database, the data returned by the DB will be useless to the attacker unless they also have access to the decrypt function in your application. By separating the two, the attacker must succesfully compromise your application and your database in order to compromise your data.
Logan
-----Original Message-----
From: Dave Bergert [mailto:dbergert_at_nobel-net.com]
Sent: Monday, April 21, 2003 9:32 PM
To: webappsec_at_securityfocus.com
Subject: Database Encryption -- Sql Injection
Does any one have any comments on where best to incorporate Column level
encryption in a Database field? At the Database Server level (via a
User Defined Function) or at the Application Level. Which would be less
impervious to SQL Injection?
I am on a MS-SQL 2000 and IIS Platform.
If I had a User Defined Function for example:
Select decrypt(AccountNumber, "key") from tblTable where User =
'someuser'
If SQL Injection occurs:
Select decrypt(AccountNumber, "key") from tblTable where User =
'someuser' or 1=1
In this case if SQL injection occurs the encrypted field will be
automatically decrypted by the UDF... Showing all accountNumbers...
If I had the Decryption handled at the Application:
Select encryptedAccountNumber from tblTable where User = 'someuser'
And had the application call:
AccountNumber = DecryptFunction (ResultSet ("encryptedAccountNumber" ),
"key")
If SQL Injection occurs, the only way data could be seen if through
whatever mechanism the application displays the AccountNumber
(Are these scenarios identical ?)
I know that encryption is not a substitution for good input sanity
validation.
Which method would be better to implement?
Thanks for comments.
Regards,
Dave Bergert
Received on Apr 22 2003
Intro
