

Author: Chip Andrews <chip@sqlsecurity.com>

This readme is for the 1.0 version of the MSSQL Server Websleuth Plug-in

*Currently this plug-in will only work with SQL Server 2000 due to the trace routines

This plug-in takes a different tack at detceting SQL injection attacks than
the formtest plug-in although at first glace it appears similar.  This plug-in
can help detect when data that is sent through the presentation layer makes it to 
the data services layer (i.e. SQL Server).  The problem with detecting SQL injection
via forms is that you are dependent upon error messages to alert you to the problem.
Most developers will seek to hide error messages from clients in order to provide a 
more professional appearance.  This can lead to many false negatives when SQL injection
is actually occurring.  Having developers disable all of their error handling just so
you can run some "security" program is probably not going to win you any friends.

As an alternative, this plug-in works by opening up a trace on the SQL Server that is 
serving as the back end to the web site in question (you provide the SQL Server name and SA account password needed for the trace).  The requirement of SA access also ensures that this tool is not used by unauthorized personnel.  This trace records any SQL batches or stored procedures that make it to the SQL Server and matches a filter as defined by the "Injected text" field on the plug-in's form.  After the request is made, the trace is re-loaded and checked to see if it contains a match.  Remember - you want to inject something that should *not* make it to the SQL Server.  The sample z'z should work in most instances.

Please provide feedback with any ideas or issues.  Already on my wish list is the ability to more proactively submit forms.  The methodical approach of posting the fields one at a time is fine but because of server-side input validation (I'm talking required fields here), you may end up with false negatives where the app was vulnerable but the validation routines kept our SQL from hitting the back end.  This is not a simple task but I image the first revision will post all variables at once or load the others with some dummy values.  Nobody ever said it was going to be easy.




