We’re continuing our series on specific security concerns and how we protect against them.  This week, we’re talking about SQL Injection And Why Your Servers Need Protection.

Websites And Databases

The vast majority of websites and applications use some kind of back-end database these days.  We use databases to store things like login information and permissions, as well as the actual content of a website.  This blog post is saved in a database, and is pulled out and rendered onto the page for you by our servers when you request the page.

Databases speak their own language, known as Structured Query Language, or SQL for short.  SQL is a way to tell the database what we want it to save for us, and what data we want back out of it.  And it’s honestly not that difficult to understand.

As I mentioned, this text comes out of our WordPress database, and so the web server has to go and ask the database for this article when you asked the web server for the page.  The database is not accessible on the Internet, so you can’t just send SQL requests to our database and get a response.  However, the web server has to have permission to talk to the database, otherwise nothing would work.  So the web server constructs a little SQL query, and asks the database – please can you send over the content of the SQL injection article as soon as you can.

This all works an absolute treat.  It’s Interwebz witchcraft at it’s finest.

So What Is SQL Injection?

We already decided the web server needs to be able to ask for data out of the database server.  The database has to trust the web server, and does pretty much anything it asks.  So what if you were able to trick the web server into asking the database for more information that it should?  What if, instead of asking for this article from the database, we asked for an article which hasn’t been published yet?  If you tried to do that, you’re trying SQL Injection.  You’re injecting SQL code into the normal webpage request.

In our case, this probably isn’t the biggest deal, since this server is only used for blogs.  Read more about different security levels for different servers here; https://beatyconsultancy.co.uk/how-secure-is-secure-enough.  But what about if this were an online shop?  What if you could see other people’s orders?

But it gets worse!  SQL is also used to write to databases.  So if you were able to inject a SQL command into the request, there’s nothing to stop you making a change to existing data.  You could deface a website in this way, or going back to our online shop example, update or remove an order.

SQL injection = bad.

Protecting Your Servers

We agree our servers need protection, but how do you go about it?  As we have described in previous blog posts – go for the easiest fixes first.  After all, attackers go for the easiest exploits first.

Permissions

Make sure your website only has permission to talk to one database on your database server.  A database server usually comes with an administrator account called root, and root has access to everything.  Some websites use this root account to talk to their database, which can be super dangerous.  If an attacker is able to inject an SQL command into such a website, the database would do literally anything they ask – including deleting everything.

Backups

Another cheap and easy mitigation against SQL injection is to have regular backups.  Backups are so important for so many reasons, and this is yet one more.  If your system is compromised by an SQL injection attack, at least you can put things back the way they were without much effort if you have a recent backup.

Updates and Patches

Now on to the ways we can actually stop SQL injection attacks from happening in the first place.  Keep your stuff up to date!  Again, cheap and easy to implement, but not everyone does it.  Have a routine for updating and patching your servers, and testing those patches.  Patching and testing should be automated if you can help it, or at the very least, it should be a boring repetitive task every month.

The reason it’s so important to patch servers is because vulnerabilities like SQL injection and others are always being found in software, and fixed.  For example, you can check out the vulnerabilities found and patched in WordPress here.  But because so many servers remain unpatched, it’s worth attackers scanning the Internet, just looking for servers still running these vulnerable versions of the software.

Web Application Firewall

And the most comprehensive, but advanced, way to combat SQL injection, just like some of the other types of attacks we’ve spoken about in recent weeks, is with a Web Application Firewall, or WAF.

A WAF is on the lookout for requests which don’t look quite right.  A SQL injection attack has a very recognisable pattern, and a WAF is amazing at recognising patterns.

When it detects an SQL injection attack trying to reach your servers, it blocks that connection, without effecting any other legitimate connections from real customers and users of your systems.  A WAF can even block vulnerabilities in software before they’re patched!  WAFs are proper magic.

So now you know all about SQL Injection.  And as we always like to say, now we understand how the bad guys work, we can protect from them.