SQL Injection Attack Cleanup Script + FREE Tools

Is your Microsoft IIS based web site getting hit with SQL Injection attacks? Are you seeing lots of javascript embedded in your database?

These situations can be a total pain to cleanup, which is why we’ve written the script for you.

Here’s what it does:

• Searches all attackable tables and fields in your Microsoft 2005 or SQL 2000 database
• Counts the number of rows that have been hacked
• Cleans the string out of the fields, including text/ntext columns
• VOILA! You are back up and running.

Note that this is for attacks that use string insertion — truncation or deletion will not be fixed by this script.

INCLUDES FREE EXTRAS: SQL injection prevention code (for Active Server Pages and Microsoft .NET) and a free script for automating daily SQL Server backups to disk.

GUARANTEED TO WORK — OR YOUR MONEY BACK!: We’re so confident that this will clean your database, we’ll give you a 100% refund if it doesn’t work. If you have problems, contact us for support and we’ll help you through.

Press the “Buy Now” button below — only $64.99

(Don’t have a paypal account?)

How to find + stop SQL injection attacks

There’s a lot of stuff out there about SQL injection attacks (including our handy cleanup script), but there’s not much that will help you figure out how to stop these attacks from occurring.

First, let’s talk about what a SQL Injection Attack really is. Some people think it’s a virus of sorts, that is “inside your site.” Not the case. These are bot attacks by other virus infected computers. They simply use a brute force approach of scanning URLs that take POST/GET inputs and attempt to send their own data to them.

So, how do you track these down and stop them? For web sites powered by Microsoft’s IIS, here are our suggestions:

1. Look at your IIS logs
   Try searching for the word “DECLARE” or “EXECUTE.” If you’ve been hit by an attack, these will more than likely show up in your IIS logs — at least for any attack that was attempted using “GET” posts. If you do find any instances of “DECLARE” or “EXECUTE” these are the pages to start with.
2. Use centralized database connection handling
   Simple, make a centralized file (e.g. connection.asp if you are using ASP — see our free example) that handles all of your DB access. This way, it’s easier to make sure that you are SQL encoding your pages. You can easily search queries for “DECLARE” and “EXECUTE” and stop the attacks dead in their tracks.
3. Implement a site wide solution
   If you are running your own server, we highly recommend ISAPI_Rewrite from HeliconTech (http://www.helicontech.com/isapi_rewrite). This is an ISAPI filter that allows you to do a variety of things, including scan URL data. This will stop 99% of attacks without changing ANY code on your site!

If you have any questions, tips, or comments, please use the contact us link above.

Scheduled restart of SQL server

As you may notice, Microsoft SQL Server will gradually consume more and more memory after it starts…Most people (us included) will wonder if this means that there are memory leaks or unclosed connections.  While you should make sure to close all unused connection, this is actually normal behavior — just check the Microsoft knowledge base #321363. 

While there are a variety of memory configuration options, we have a nice bandaid fix: restart SQL server during off hours.  Simply make a .bat file with the code below and use windows scheduler to run the file when traffic is low:

@ECHO OFF
NET STOP SQLSERVERAGENT
NET STOP MSSQLSERVER
NET START MSSQLSERVER
NET START SQLSERVERAGENT

SQL 2005: Truncating Log Files and Recovering Space

A common issue for users of SQL Server databases is disk space and the size of the physical log file and database. While we’re not going to attempt to make “one size fits all” statement on database maintenance plans, we though it would be helpful to provide a few suggestions that will help you trim the size of your files when you are in a pinch.

Steps to truncating log files and shrinking your database:

1.  Get the physical names of your database file (MDF) and log file (LDF):
Run the following system stored procedure:

use <yourdatabasename>
exec sp_helpfile

This command will return a variety of information, including the physical size (the “size” column) and the path and name of your database and log files (in the “filename” column). 

Record the name of the file from the “filename” colunm, excluding the path and file extension (e.g. if filename contains “C:\sqldatabases\yourdatabase_data.mdf” you want to save the string “yourdatabase_data”)

2. Truncate the database and shrink the database
The following set of SQL will shrink your database and “truncate” the log file. File in the parmaters surrounded by <…>.  Note that you’ll need the two filename values from step 1.

USE <yourdatabasename>
GO
BACKUP LOG <yourdatabasename> WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE (<yourdatabaselogfilename>, 1)
GO
DBCC SHRINKFILE (<yourdatabasedatafilename>, 1)
GO
exec sp_helpfile

When complete, this script will output the same information as in step 1.  Compare the new size with the old.