Editorials

First Line Defense Against SQL Injection

SQL Injection has a number of different techniques, some of which are available based on the way you have configured your SQL Server engine, database security, and database access by your application.

Let’s start with the SQL Service. The best way to thwart SQL Injection is to limit the permissions of the SQL Server service. This is done by creating an account to use for your SQL Service. This account has very little permissions. It is restricted to a certain set of directories for database executables, backups, data files, transaction log files, and log files. By restricting directories, any user able to get System Administrator privileges will be highly restricted to the capabilities of the account used to host the SQL Service.

The second layer of protection against SQL Injection is completed though restricting the permissions of the account used to connect to your database for your application. Regardless of using SQL credentials or Active Directory credentials, you need to restrict capabilities of your application.

Some applications do not allow any application to have Database Owner role permissions. As a result, the application cannot, out of the box, do anything. Explicit permissions to procedures, views, functions and tables are explicitly granted, or granted through the use of schemas. As a result, many forms of SQL Injection are thwarted, because the login does not have permissions to execute man kinds of Injection Queries.

For example, one popular injection query is “SELECT * FROM INFORMATION_SCHEMA.TABLES”. By restricting your application account permissions, it won’t have access to the INFORMATION_SCHEMA.TABLES view.

Active Directory is a great way to manage the credentials used for both the SQL Service, and the Application Service. Local Windows Service accounts may be used, but are not as easily managed. Likewise, SQL Server accounts may be maintained, and SQL Server Authentication can be used. However, Active Directory, or other kinds of credentials are preferred as more secure, or centrally managed.

Optimizing your credentials, when connecting to SQL Server, does not counter all methods of SQL Injection. It reduces the amount of opportunities to only those in the databases to which your application can attach.

Are you managing the credentials in your databases?

Cheers,

Ben