Website defaced, a victim of SQL Injection?

If you run a website, particularly if it provides an income or you it's the one thing you dread to see in the morning.  Your site has been hacked and your content changed, in fact all your hard work has been defaced with links to goodness knows what.  There are many ways that malicious individuals can use to access your site content, but one of the most likely methods is to use what is called SQL injection.  They use the flexibility of your very own database to deface your content for their own gain.

This has happened to me only very recently after I rushed to release a new version of my website and very carelessly didn't test it properly before it went live.  Well, a lesson was learnt there and fortunately I was able to recover fairy quickly and plug the hole that allowed the hackers from Korea to gain access to my database.  Actually, the term ‘hacker' is perhaps paying these people far too much of a compliment, because it doesn't really require skill and is dependent wholly on the carelessness of the webmaster. 

There are tools that you can use to scan your website and detect any vulnerabilities including susceptibility to an SQL injection attack.  I suspect they use some of these very tools to indentify websites that are vulnerable so my advice would be to get there first!  There are too many of them out there to list here, but a quick Google search should get you started.

...check EVERYTHING that's going live!

First of all sanitise the data you are passing to your SQL queries.  There is plenty of information out there about this.  For example, convert you're input data to integers if an integer is required in the query.  Either HTMLencode or URLencode text strings to get rid of those nasty single quotes that are the root of the problem.  Yes, I was doing a lot of this but in my haste to release my site left a few test scripts wide open.  Always check EVERYTHING that's going live!!  It's a no brainer really, but we all slip up now and again.

One of the things I noticed when my site was compromised was that they had appended their links only to certain fields.  I'm using a SQL Server database and they happened to be targeting only the varchar(max) fields.  Presumably this is because they're assuming there would be enough space to attach the spam to!  More interestingly they only went for the fields which had names such as "title" or "name".  It goes without saying that if my fields had been called MN1, MN2 etc.  then I might not have been caught.  The downside of more obscure naming is that it's less easy to remember when you are writing queries yourself and may not make sense to you or anyone else who needs to work with the database later.  Well there's a plus and a minus to everything I suppose.  I'll go for securing the code first and next time round consider my options when naming fields.

Another thing I noticed was that the script they targeted had a request parameter "?page=" and again these were the ones that were used.  There was a vulnerability elsewhere, but it was this that received the attention.  Thinking about it, it's a fairly common thing to do, to use a parameter such as "page=".  Again, if I'd been a bit more cryptic then it might have been missed.

I'm glad that I was caught in a way because it has made me much more aware of the techniques used and some of the methods I can use to deflect these attacks, the most important being sanitising input parameters and not being so sloppy as to release code that hadn't been thoroughly vetted in the first place!!  I was very lucky in this instance that more damage hadn't been done.  As it was many of the defaced pages were indexed by Google and of course there will be a knock-on effect from that.  Things could have been much worse if I hadn't fixed it as quickly.

© 2009-2011 Mothsworld.com - All rights reserved.  Please see our privacy policy and disclaimer.