So, the other day I check into a small online community that has a small forum area where, among other things, people will sometimes discuss web development issues. While there, someone gave this bit of advice, to paraphrase:

Oh, as long as it's an application you programmed yourself, it's not really a big deal for you to have to take care of those old SQL Injection vulnerabilities. You can probably just let it wait until you upgrade the programming to a newer technology

I was a bit flabbergasted that someone would say such a thing, but it just so happens that I have, on hand, logs that prove that the assumption backing up that feeling of security is not at all based on reality.

Injection Bait

A little while ago, I set a client's database-driven web site to report errors to me generated as a result of attempts to exploit SQL Injection vulnerabilities. Normally, this sort of thing is "background Internet noise" that isn't terribly worth looking into - like 'port scans' on your home router. But I wanted to see what sorts of things were being tried. Also, since I had created all the code behind this site from the ground-up, I actually was curious how much I might see targeted SQL Injection attacks. The answer? Twice a week, average.

Of course, the WWW request logs contain lots of probing requests looking for certain popular web applications which have/have had SQL and other vulnerabilities. I swear I still occasionally catch sight of that now ages-old, telltale string of N's from Code Red in there, too... But these particular messages I was setting myself up to get were actual web application exceptions, caught when input fields have been tampered with to contain specially malformed values.

Sample Data

Some examples of the querystrings (line-breaks added to prevent exploding layouts!):

?by=statemap&id=43'%20And%20char(124)%2b(Select%20Cast(Count(1)%20as%20varchar(8000))
%2Bchar(124)%20From%20[sysobjects]%20Where%201=1)>0%20and%20''='

?by=statemap&id=43%20And%20char(124)%2b(Select%20Cast(Count(1)%20as%20varchar(8000))
%2Bchar(124)%20From%20[sysobjects]%20Where%201=1)>0

?id=terms%27%20And%20char(124)%2b(Select%20Cast(Count(1)%20as%20varchar(8000))
%2Bchar(124)%20From%20[sysobjects]%20Where%201=1)%3E0%20and%20%27%27=%27

In each case, within a few minutes of a legitimate request, would come requests with querystrings like those above. The first two query strings are supposed to end after ?by=statemap&id=43. Everything else after that is the attack. In addition to sending me a report on the attempt, the attacker gets a friendly error page saying something happened, and it's been reported to the web master. The 'friendly' part is that it's a nice page which is part of the site's design, but also - it contains no technical details except a simple number "500".

After a couple requests, getting nowhere - not even a detailed error message as a hint - the attackers leave. A few try out some cross-site-scripting shenanigans on pages which accept textual query data. Unfortunately for them those, too are caught, reported, and given a 'friendly' error message.

So, What?

Why do I think these represent targeted attacks? First, let me clarify; I do not mean there is someone with a grudge against me or the client whose site it is, looking to deface it or steal their data specifically. What I mean is this is not merely a random worm just indiscriminatel blasting itself all over the place. Web pages are being physically browsed by a human being to identify them as accepting query string values. Then, instead of a thousand 'brute force' attempts to exploit possible vulnerabilities, a handful of fine-tuned requests are made just to test to see if there is something worth looking into further.

And also, as I noted, this site's code was created from the ground-up by me, so there were none of those ultra-common web applications being used (hmm... like BlogEngine.NET, for example?) This part gets a bit on shaky ground, because I know that any part of the request logs could represent spoofed or proxied source addresses. However, there was no evidence of immediately prior or subsequent attempts at anything other than the handful of specific attack probes.

Conclusion

A site with a vulnerability such as those being discussed at the community I noted above would have instantly fallen to the attacks here. Who knows... perhaps it already has/had. At the very least, such a site could be quietly taken over and used to host illegal material. Developers who use APIs and other schemes which all but preclude the possibility of SQL Injection vulnerabilities in new code might want to consider legacy code again. In fact, that whole situation prompted me to do a quick review of the script on an older site. I didn't find any SQL injection vulnerabilities, but I did have an ugly trip down 'spaghetti code' memory lane...