Tuesday, July 26, 2005

Ten Signs Your Application Is Susceptible to SQL Injection Attacks

10. The database used by your application has admin accounts with default passwords (or even worse, no passwords at all)

It may sound obvious, but it wasn’t until after the SQL Slammer virus navigated the Internet in 2003 that Microsoft began requiring a password for the SA account.

9. Your application uses an account with administrative privileges to connect to the database.

Another obvious one, but how many code examples on the web have you seen that uses SA when talking to a MS SQL database.

8. Your application ignores the least privilege principal when connecting to the database.

If you have an application that only needs to query a database, then use an account with only read-only permissions. Also ensure that the only accessible tables to that user are those that are required by the application.

7. Your error messages display too much information to the user (i.e. stack traces, connection strings).

An example from thedailywtf.com, a site that posts actual application code and asks the question WTF?!:

   Item has already been added.  
   Key in dictionary: "data source=DTESQL04.INITECH-GLOBAL.COM;initial catalog=BCPCMS;user id=cmsadmin;password=flTSP4#1;"
   Key being added: "data source=DTESQL04.INITECH-GLOBAL.COM;initial catalog=BCPCMS;user id=cmsadmin;password=flTSP4#1;"]
 System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add) +931
 System.Collections.Hashtable.Add(Object key, Object value) +11
 Initech.BcpCms.Data.ConnectionManager.EnsureConnection(ConnectionProvider provider, String connectionString) +667

6. Your application does not limit the number of characters in input fields to a proper amount.

If your password policy asks for password 3-12 characters in length, then don’t allow the user to enter 255 characters or more. Otherwise, it is too easy to inject extra SQL code into the request.

5. Your application builds SQL statements on the fly (dynamic SQL)

Use parameterized queries or stored procedures to access a database as opposed to building sql statements on the fly. Yes, this makes it harder to change or modify the query, but that’s the point.

4. Your application fails to validate the output

If you only expect one row to be returned from the database, doublecheck the return results to make sure that one and only one row is returned.

3. Your application does handle improper characters like ‘ or ;

Several years ago, a single message on an Internet forum invoked the devious nature of its members. The message simply pondered what would happen if they changed the URL displayed in a web browser from - http://mybank.com/default.asp?id=3 to http://mybank.com/default.asp?id=3;SHUTDOWN.

The URL managed to submit a request for the database server to shutdown and the new banking site was instantly unavailable.

2. Your application does all of its validation on the client

As a general rule, validation on a client is for user friendliness. The server should always do the primary validation. (And make sure to do the validation before your application consumes it.)

It is too easy to intercept requests from a client, modify them, and forward them on to the server. This is especially easy for web applications through the use of a proxy. Programs like Web Scarab are very good at this.

And the number one sign that application is susceptible to SQL Injection attacks…

1. Your application communicates with ANY sql database

No SQL database can avoid be exposed to these attacks. Whether it be Oracle, MySQL or MS SQL, a valid SQL statement can be manipulated to return unexpected results.

However, being aware of this fact and taking steps avoid SQL Injection attacks is the first step in building up your application’s immunity.

Post a Comment