If you have a static website (meaning it’s just .html) that you’ve uploaded via FrontPage, FTP, or whatnot, the single most important thing to do is choose a good password and keep it secure.
One class of site hacks is simply people getting the password, ftping in, and monkeying about with files on the site.
While that does happen, it’s actually not the most common cause for a good number of site hacks these days.
That gets a little more technical.
SQL (for Structured Query Language) is a database programming language (although the term is often used generically to refer to the fact that a database is being used).
Many, MANY sites are SQL driven, particularly e-commerce sites and almost all blogs, including Ask Leo! and almost all of my other sites.
What is SQL injection?
When it comes to programming, SQL statements are the epitome of “think differently.” It’s a programming language, but you really come at things sideways compared to more traditional languages.
A web page might cause this to be performed in response to a user’s search request for a “pencil”
SELECT * FROM Products WHERE Description LIKE "%pencil%";
That would search our mythical database and return all of the products that have the string “pencil” in their description.
Pencil was probably something typed in by a site visitor in some kind of search field.
So, what if a malicious visitor typed in this?
"; DROP TABLE Products; SELECT "
If the website programmer wasn’t careful and just plopped that into the SQL syntax he was using for search above, it might turn into something like this:
SELECT * FROM Products WHERE Description LIKE "%"; DROP TABLE Products; SELECT "%";
By “injecting” that SQL fragment into the search field, the original single statement actually turns into three:
SELECT * FROM Products WHERE Description LIKE "%";
DROP TABLE Products;
And the second statement would actually delete the database called Products. The site would probably be toast thereafter.
THAT is a SQL injection. I used “DROP TABLE” as a simple example, but in reality, any valid SQL syntax could be placed there. If the hacker experimented long enough, they could do things like print the entire database.
Now, imagine if instead of “Products,” our database was “Users.” The hacker could display the entire database of users.
Using SQL injection to poison a site
It’s possible that dumping or deleting a database might not be the hacker’s aim at all. Maybe making changes to the information about a product is enough.
That same SQL injection technique can actually *change* the description of a product.
It’s significantly less dramatic (the site continues to work just fine), but with a much more subtle impact (visitors walk away with MUCH more than they bargained for – malware).
If you’re writing web pages that use SQL, you must learn the term “input sanitization.” It’s actually more complex than I can get into here, but fundamentally, you must use techniques to prevent SQL injection from happening. They’re sometimes complex (hence, the fact that SQL injection remains common), but necessary.
Content management systems and SQL
Content Management Systems (CMS), like WordPress, which are SQL-based, have had to seriously harden themselves over time to these types of attacks. There have been bugs in them that allow SQL-injection to occur on purely content sites.
If you’re using a CMS – any CMS – keep it up to date.
Much like hackers target Windows because there are so many users, hackers also target popular CMSs like WordPress for the same reason. Figure out how to hack one, and you can hack thousands.
The single biggest reason for website hacks these days are web owners not updating their CMS.
Anti-virus and websites
Many folks wonder if the web servers should run anti-virus software.
Consider, for example, how visiting http://askleo.info actually takes you to http://askleo.com. If that were hacked, it could easily take you to some other random web server loaded with malware. Of course, that other web server is out of your control.
Oh, and that’s a one-line hack (in the right place, of course).
Protect your site as above: standard login security and keeping software up-to-date.
What I do
The only hack or malware that I’ve ever personally experienced was the hack of an Ask Leo! web server many years ago. Since then, I’ve taken security extremely seriously.
I do a few things to keep my web servers secure.
For administration, I use encrypted connections (https or equivalent) as much as possible and take extra measures if I’m ever using a public internet connection. (Use plain old FTP at Starbucks? Don’t. Someone could easily sniff your username and password to login from the air.)
I require public-key authentication for secure command line and secure ftp. What that means is that I could give you the password and you still would not be able to login to my servers.
Ask Leo! uses WordPress – so keeping with my own advice above, I work diligently to keep it up-to-date and secure. I have several security-related plugins installed, including two-factor authentication. Once again, I could give you an administration password1, but that wouldn’t be enough – you still wouldn’t be able to login.
The silver bullet
FINALLY, there is one important silver bullet that can essentially save you from anything.
I backup like crazy.
The easiest, and often the quickest, way to restore a compromised server is to restore it to the most recent backup image taken prior to the problem.
Of course, that presumes you have such a thing.
All of my servers are backed up nightly.
On top of that, I also set myself a goal that if I was traveling and something happened to the site, I should be able to recreate Ask Leo! from scratch on some other host, if need be. I’ve never tested that, but I believe I have all of the pieces in place.
SO … backup: everything, early and often.