Please start any new threads on our new site at We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 .NET Inside SQL Server (2005)
 Sql Injection : Data Appended automatically

Author  Topic 

Starting Member

1 Post

Posted - 2013-06-10 : 06:28:20

I have website as as Front end and SQL Server 2005 as Back end.
But I am facing a very strange SQL injection on my back end.
Some type of CSS with HTML with spamming site is appending their code to my website database with each table and with each varchar type columns.
For e.g.
</title><style>.acoi{position:absolute;clip:rect(439px,auto,auto,439px);}</style><div class=acoi>Apply here <a href=>payday loans</a></div>

I tried all these things.
I have checked there are no query string parameters are open.
All queries are parameterized in whole website.

My IIS Server log not specifying that which page open for this.
How should I sort out this issue?

Starting Member

1 Post

Posted - 2013-06-16 : 18:46:36
We've had the same problem for six months; two attacks a week (every 4, 5, or six days usually at the same time). I'll detail how we've approached the problem - we have no IT department, so that's why we've taken so long to find a solution:
1. Tightening up code, especially as to forms and SQL queries. This didn't work.
2. We signed up to CloudFlare. It did stop the attacks, whatever level of security we used.
3. We then added a rule to our server's (Microsoft) firewall, so that all traffic has to pass through CloudFlare's cloud (one of the firm's recommendations, although we haven't had to change our site's IP, which is another recommendation). We thought that maybe the attacks were direct to our IP address. This didn't work either.
4. After that, we accessed our logs to see if we could identify the IP of the hacker and also where the attacks had entered. This was the most important move. As we signed up to Pingdom a couple of years ago, we know exactly when the attacks occurred, thus allowing us to match this data with our logs. This worked.

I know that it's not that common for an attacker to use the same IP address, but this was our case. The attacks came from a server in Moscow and the injected script was always from a loan company (maybe the site's owner isn't aware of this, but we think it's a zombie). The attacks used hexadecimal and entered via the IDs of the URLs of our blog posts. So we blocked the attacker's IP (on CloudFlare) and tightened up the code so that hexadecimal-length scripts cannot be used.

In short, Pingdom, CloudFlare and especially the logs have allowed us to solve the problem. We'll probably receive attacks in the future but we are now fairly confident that we'll be able to address them all, and fast. Also having fresh backups of the BD has also been essential; we've never been off-line more than 15mins.

Hope this helps you out.
Go to Top of Page

- Advertisement -