SQL Injection Defence

SQL injection attacks have received high publicity since the web explosion. In code reviews I see the same vulnerabilities appear on a regular basis. Developers take note.

The SQL injection attack always uses the same method. There are different approaches , but the method remains the same. i.e the data starts with (‘)  , appends the Trojan SQL code and ends with the comment mark (--) . The effect of the (--) is to comment out the original SQL intended to be submitted.

It is a common belief amongst DBAs that SQL injection attacks are an application issue . In reality , the application and database need to be reviewed in unison.

The two main approaches in SQL Injection attacks are:

a)      Implementing parameterized stored procedures with SQL code passed

b)      SQL code concatenated via client interface and passed through the application

How to defend a SQL injection attack

1)      Never use ‘sa’ or any login with sysadmin privileges. This is the highest privilege available within SQL Server and should only be assigned to the DBAs.

2)      Strong typed parameters assist in defending against SQL Injection attacks

Read more on SQL sp_executesql versus EXECUTE

3)      The IS_GRANTABLE flag is a default. And does allow permissions to be granted at any object level.  Consideration should be given to creating a policy for the security risk .  It is not uncommon for SQL Injections to occur via identifying the whether IS_GRANTABLE is set to YES or NO

Read more on : How to manage the IS_GRANTABLE security risk

Read more on Security and SQL Injection Attacks

How to create a SQL Server Security Audit - SQL Server DBA

Powershell - run script on all sql servers - SQL Server DBA

SQL Server - Powershell and Failed Logon attempts - SQL Server DBA

SQL Security Management