Saturday, January 12, 2008

Vulnerability Series: Database Error Messages

When not properly handled, database error messages may provide quite a bit of critical information to an attacker. A common cause of this error, is the failure to properly santize data being submitted to the environment. Quite often an attacker will use database error messages (or any other error type) to finger print the environment. Consider the following questions we might we might apply to this type of fingerprint:

  • What is the servers’ function within the organization?
  • What type of data is it handling?
  • What type of server is this? Is this server a Database server? Application server? Web server?
  • What system(s) or application(s) does this system or application data interact with?

Armed with this information, an attacker may be able focus on specific vulnerabilities that may exist in the environment.

How to apply this attack

There are numerous attack types for the execution of this attack-type so for simplicity, I will throw out the most common attack (which we know you have heard of)....SQL Injection. To apply SQL Injection, I would recommend seeking out a couple of different resources....

Are you looking for SQL Injection tools?


There are more than enough whitepapers out on the internet which describe the so-called "fix" for SQL Injection so we won't get into a long debate for the fix -- I'm simply going to provide my opinion and additional resources.

  • Input Validation, Input Validation, Input Validation
  • Parameterized SQL Queries
  • Use the principle of Least Privilege (on the SQL Server)
  • Turn off error messages
  • web.config for the default handler
  • Secure the server
  • Turn off error messages

One note that I would like to offer about protecting yourself against SQL Injection which deals with Stored Procedures. Stored Procedures are great and if you decide to use them in your code, I wish you the best of luck; however, stored procedures do NOTHING for protecting your code against SQL Injection.

If you are looking for the ultimate protection from SQL Injection, I highly recommend the use of parameterized queries (for more information on PQ's, please seek out one of many articles around the net (and/or Microsoft)).