This is an article about a free tool that has been developed to help users stop SQL injection attacks against their SQL Servers. For full details about what a SQL injection attack is and how to write code to defend against them see this Microsoft Advisory.
TDSe-cure
TDSe-cure is an extra defence against the incessant SQL injection attacks that web sites and applications have faced for more than a decade. While compiled programming languages such as C had protection against poorly written code like buffer overruns built into their compilers, web scripting languages like ASP have been left out on a limb. Of course there are code scanners to verify that code is robust, but they only go so far and essentially have to be run every time you update any code. They also offer no help if an attacker takes control of a web server and can run arbitary commands.
What is it?
First of all let me tell you what it is not; it is not a one stop fits all solution to fix poorly written code. You still need to make sure you verify your inputs at every stage. This is, however, a tool that will stop attacks against your applications by reading the data that is sent to SQL Server and applying a set of rules to either allow or deny the request, similar to how a firewall would work. By applying a set of rules you can stop the attack or severely limit what an attacker can do if you have vulnerable code or if they have taken control of your web server - to see how easy it is for an attacker to take over an unsecured SQL Server see http://sqlninja.sourceforge.net/ (particularly the demo page).
Where does it fit in?
TDSe-cure can be run as a standalone program or as a service, all it requires is the dotNet framework 3.5 so can work on any current Microsost OS. Basically it needs to sit between the web server and the SQL Server and listens on whichever tcp port you specify in the xml config. The most common and secure use is on a seperate server between the web server and the SQL server. The web server should be in a public DMZ with either the TDSe-cure service in the same private DMZ as the SQL servers or a third dmz. However you design the infrastructure it is important that the only ports open for SQL traffic between the web and SQL servers are through this service.
This shows the different scenarios for fitting in TDSe-cure into your environment:
How does it work?
The application acts as a proxy service for the traffic that goes between the web and SQL Servers. It decodes the TDS packets and applies a set of rules to the text that SQL sees - this is the actual text not something that will then be html decoded or will be modified by a web server so we can be sure that the text we are verifying will not be then transformed to do something we did not expect. In the default mode (token mode) you can specify a set of tokens that are checked against the text, so for example most SQL injections use the comment characters (-- or /*) to work, so if we dissallow these then we can stop an attack in it's tracks.
The other two modes use the power of regular expressions to allow or deny requests - lockdown mode and banned mode. Lockdown only allows a request if it matches a specifically allowed batch, this means you can limit your application to only being allowed to run the SQL commands it requires - this is the most restrictive and time consuming to configure but will give you 100% security if it is configured correctly. The second of the regex modes is banned mode, this allows all batches but denies a specific set of batches - this is useful if you have an application and it is secure except for a handfull of known issues, you can apply these rules to stop the batches while a code fix is put in place. You would only generally use the banned mode along with token mode to secure your SQL traffic.
As well as the three modes we have already discussed you can add additional batches which would fail the other tests (for example a batch with a comment it) and you can write a regex to match when that is being used correctly and allow it, this give you the added flexibility of using TDSe-cure without having to modify all your existing code at once.
What happens when you get a bad request?
There are two courses of action TDSe-cure can take, the first is to close the network session and kill the link between the application and the SQL server. The second is to return a permission denied error message as SQL would if the user didn't have enough rights to perform the request. In future versions you will be able to specify a response (i.e. return a a row of data or a custom error).
The application can also send an alert to say that there has been an attack, this is either through email or by writing to the event log (or both). It is also possible to set the application into a logging only mode where it alerts on potential attacks but does not stop them, this lets you identify how many false positives you would have had and allows you to either change modes or add batches to the additionally allowed requests.
How do you get it up and running?
The first step is to install the service, you can download the application from here. When it is installed, inside the installation directory is the xml config file, one for the service and one for the command line app, it is useful to use the command line app to get the config as you like it and then use the same config for the service.
Where to get more help?
To get more info on TDSe-cure you can take a look at www.TutisDatabaseServices.co.uk or email TDSecure@TutisDatabaseServices.co.uk
