SQL Injections – why companies should care (and users, too)

While I had read reports about successful mass SQL attacks on hundreds of thousands – by some estimates even millions – of websites months ago, I didn’t really care much, assuming that this issue would only concern outdated, irrelevant and poorly coded websites.

I realized I was wrong (partially wrong) about a week ago when I was looking for recipes for my newest toy, a blender from a brand every YouTube user knows. Unfortunately, the manufacturer’s website contained not only recipes, but also references to a malicious external script:


For a moment, I thought about making a stupid video showing some JavaScript that does not blend but then decided on contacting the company first. Indeed, only one day later the site had been cleaned.

Normally, I wouldn’t even mention this on my blog, since I believe “public shaming” is only justified if a company or webmaster does not react withing a reasonable time or if the case at hand is particularly outrageous (before you disagree, please consider that my entire blog is about not being perfect and still having a lot to learn). However, when I visited the website again on Sunday (in order to show the company’s products to a friend and restaurant owner), NoScript showed the site had been compromised once more and was trying to distribute malware again (this time, the evil domain was mainadt.com instead of suppadw.com). When I tried to send another message over the contact form this morning, Firefox 3 wouldn’t even let me visit the page without a very clear warning:

The reason Firefox is showing this warning is that Google now “officially” considers this site (possibly) harmful:

Aside from the obvious “make sure your code is not vulnerable to SQL injections (and don’t forGET it’s not only about POST parameters*), what can be learned here?

If your site has been compromised, you should react quickly and make sure it can’t happen again. Otherwise Google will sooner or later list your website as “suspicious” and you’ll certainly lose visitors and business. A compromised website also reflects poorly on your company and your brand. I would be particularly concerned about the negative effects in the case of companies relying heavily on the internet for business (including internet marketing). Furthermore, one has to wonder if you might be held liable for exposing your visitors to malware.

Don’t rely on expensive third party scanning tools. Did you notice the “Hacker safe” logo in the first screen shot above where my virus scanner was already showing a warning? Instead, I suggest hiring a capable programmer (you’ll need one to fix the vulnerabilities anyway) and have him customize a monitoring solution which issues a warning anytime your website or database has been “illegally” modified (I might pick this idea up in a later post). This would make sure you’re the first to realize when something is wrong, not your visitors or Google.

If I were a capable programmer familiar with ASP and MSSQL and had some free time, I’d think about spending a few hours searching for affected websites, somehow ranking them (e.g. “best known”, “in my area”, etc.) and then contacting them with an offer to remove the malicious code and the vulnerabilities (or maybe redesign the entire website). Think about it, there might be millions of affected websites out there, this seriously screams “business opportunity” (BTW, I’m not a… er, not familiar with ASP and MSSQL and I’m busy, so please don’t contact me). Of course, sooner or later someone’s bound to misunderstand your offer (“this guy hacked our website and now he’s asking for money”). 😉

As a user, don’t follow my bad example in the first screenshot. Instead, disable JavaScript by default and enable it only for sites you can trust. This can be done best by using the excellent NoScript plugin for Firefox. Don’t think that Firefox + Google alone can always protect you, you won’t get the big red warning above unless the site in question has been compromised for some time.

*technical details can be found in Michael Zino’s article ASCII Encoded/Binary String Automated SQL Injection Attack and by following some of the links I posted before.

One thought on “SQL Injections – why companies should care (and users, too)”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.