New MS blog posts today on SQL Injection:
Download locations for the new tools:
What is SQL Injection?
SQL Injection is a method where people are able to change the code submitted to SQL to something else. It’s not something you can prevent on the database side with a configuration change or anything like that, though improving your server side security is key. You have to change your stored procedures, functions, and dynamic TSQL code to not allow the potential for injection of other code. The same basic steps apply whether it is SQL Server, DB2, Oracle, or any other relational database.
What can you do to stop SQL injection?
· Limit the permissions granted on the server and to each user. Remove as many logins as possible from the sysadmin and db owner roles as well as any other role that has more than the absolute minimum necessary permissions. Only grant permission to views and storprocs, not to the underlying tables.
· Enforce strong password policies.
· Limit the security enabled for linked servers.
· Disable attack vectors such as xp_cmdshell, OPENROWSET, and CLR unless you are using them for a specific purpose.
· Restrict access to attack vectors such as sp_makewebtask and xp_sendmail.
· Don’t allow dynamic queries to be built from end user free-form input.
· Use parameterization.
· Write error messages carefully. Give enough information to troubleshoot without exposing vulnerabilities to hackers. You may write more detailed error information to a table in the database and return a less descriptive error to the client (with a good but untraceable way to link the message to the proper error row in the database).
· Check the data type of incoming parameter values. For example, if you’re expecting the user to put in a last name to be checked against a column that allows no more than 30 characters, limit them to 30 characters of input to reduce the chance they do something like
o Expected: WHERE LastName = ‘Smith‘ (they just enter: Smith)
o Injection: WHERE LastName = ‘Smith’ ; SELECT * from syslogins‘ (they enter: Smith’ ; SELECT * from syslogins)
· Limit the total length of any arbitrary string submitted to SQL Server.
· Set up query filters to exclude known injection vectors such as 1=1, drop, create, sp_addlogin, 1/0, escape characters, http, etc.
· Establish an audit trail (such as SQL Profiler always tracing certain types of events or triggers to track data changes).
· Periodically review or even set up alerts for events in the SQL Server and IIS logs.
· Disable addons and ActiveX controls in your browser.
· Run anti-virus and anti-spyware applications. Make sure you exclude SQL Server files from the scanner to avoid impacting SQL performance. You also have to disable then during setup.
References: