Webmaster Forum / ASP / Database Access / August 2008

That is a poorly considered approach, for at least the following reasons
(likely many more):

1. In between each successful SQL injection attack, and the next automated
cleanup, your site's visitors are subjected to client-side attacks when the
malware javascript that was injected into your data runs in their browsers.
That is irresponsible, and will surely cost you users as time goes on.  (For
me personally, the first time I noticed it would be the last time I browsed
your site.)

2. The overhead incurred by both the SQL injections and the clean-ups could
be substantial, and is definitely 100% wasted compute and resources.

3. Those SQL injections can be quite sophisticated, making complete clean-up
difficult, if not impossible to program.

4. The SQL injection attacks I've seen truncate data when max field length
is not sufficient to permit storing both the data and the injected crap,
which means loss of data without restoring a backup.

By accepting that the attackers will be able to write to your SQL Server
data, and accepting the [mistaken] premise that there's nothing you can do
about it, you practically join their ranks.  By relinquishing your right to
your own data integrity, your right to be free from their corruption, you
also relinquish your user's rights to be safe from attack by vandals and
theives while browsing your site.

What you describe is no solution, it is a surrender, to those that lack even
a shred of decency, or any respect for the property of others. And for
merely the false sense of contentment you get out of calling this a
solution -- and not one tiny single thing more -- you've sold-out your user
base, to the jackals that are going to harvest every fiber of their
collective being, just to make a dishonest buck.

As god would be my witness [if only there was one] you have folded, man, you
lose.

-Mark