So here’s a thing about me: I hate getting shots. I break out in a cold sweat. Any kind of injection needle freaks me out, and I hate the way it feels before, during and after. As much as I hate them, though, injections are a great way to put something directly in the bloodstream, and to bypass lots of other body systems that medicine might have to go through if taken orally… or through some less pleasant way. Injections make me practically pass out… but they’re way worse for websites!
Why SQL Injections are Dangerous
There’s a specific way that websites can be hacked, and it’s called a SQL (pronounced “sequel” stands for Simple Query Language) injection. When a website is vulnerable, a hacker can use something as simple as a sign-up form to completely take control of the entire server the website is running on. Once the hacker uses a SQL injection they can delete things, create new users, change your website, and download sensitive information. In fact, SQL injection is the number one way websites get hacked. In this article, I’ll explain how it works, and some best practices for websites to guard against them. And if you or your company have a website, you need to be aware of this vulnerability. And if your company doesn’t have a website, you’re probably more worried about your horse & buggy maintenance than SQL injections.
How it Does the Damage
Most websites are dynamic. This means that the information you see on the screen when you visit a site isn’t saved as a single file somewhere on a web server. Instead, the page is built dynamically when you visit it. Using information about your screen, browser, computer, date, and using login information, the website retrieves data stored in a database, and presents it on the webpage. When you do a Google image search for “Cats playing poker”, Google doesn’t have a page already saved of gambling felines, instead it asks its massive database for any such images it’s encountered on the web, and then puts them all on a page for you.
Now let’s say your website is designed to be personalized for visitors who log in, so you have a sign-up form that simply asks for a name and a password. The sign-up form will store the information entered in the name field (eg. Doug) and use it to execute a line of code that saves it to the database. The code might look like this: Tell the database to store “DOUG”. Of course, it’s a little more complex than this, and the code used special language (SQL commands) to write to the database. But now let’s say our nefarious hacker comes along. And instead of just putting “Doug” in the name field he also adds some SQL commands at the end of his name. Now the website runs the sign-up form again and process it, but this time it looks like this: Tell the database to store “Doug and delete everyone else” or Tell the database to store “Doug and give him complete control of the website”. The database will happily comply, and the hacker is now an administrator on the entire web server. As you can see, this is not a good situation. Obviously, it’s not quite as simple as I portrayed it, because the hacker would have to know the correct SQL commands, and have a good idea of the names of databases, etc. but it’s honestly not far off from this simple scenario. So how can we protect against this? By adhering to best practices, which takes a little effort and means no cutting corners.
Best Practices
There are really two main ways to protect against SQL injections; parameterized data and stored procedures. I’ll explain in layman’s terms what these mean.
Parameterized Data
This simply means that when we give users an opportunity to enter data on a website, we limit the response with some very specific rules (aka parameters). For instance, if we ask for a username, then we limit it to a single word. Anything beyond that gets chopped off before being sent to the database. Or we sanitize anything coming in from a page by specifically looking for SQL commands and stripping them out of text entries. The parameters we set dictate what can and can’t be submitted through the webpage. It can even convert every letter in the text into hexadecimal code, so that it can’t be executed.
Stored Procedures
Stored procedures are a list of preset commands to be sent to the database. This list is very limited and very specific. And only items from this list can be sent to the database as commands. When a user enters information on a page and submits it, that data never goes to the database, it just triggers one of the code commands in the preset list. While this is somewhat limiting, it means nefarious code can never make it through to the underlying server.
In short, don’t allow dynamic SQL on your website, which SQL commands that are built on the fly from user submitted data and then sent to the database to be executed indiscriminately.
Is All This Really Confusing?
At Bit-Wizards we have a suite of tools at our disposal that we use to check websites for vulnerabilities. Your business depends on your web traffic, and getting hacked is generally very costly and damaging. If all this sounds confusing, but you are concerned about your site,
just give us a shout!