Chatting with developer Frank Korf about SQL injection, the attack used to breach the Illinois State Board of Elections

This is the first in a series of short interviews we’ll be conducting with Earlybird technologists on various issues relevant to our clients. Have any questions or ideas for topics you’d like to see us cover? Drop us a note at hello@earlybird.co.

Eddie VanBogaert, Partner: Here in Illinois, the release of stolen emails from the Democratic National Committee isn’t the only news headline to involve both information security and the upcoming election. Late last month, officials with the Illinois State Board of Elections confirmed to reporters that they were hacked as well, not for their email messages, but for the database they maintain of the state’s registered voters.

In a statement to county election authorities, SBE’s general counsel relayed assurances the breach was fairly limited, emphasizing there was no evidence indicating any records were changed or destroyed. Still, as a precaution, the online voter registration website was taken offline for over a week, a seriously concerning outage this close to the general election.

Unlike what happened at the DNC, the SBE hack isn’t thought to be the work of advanced cybercriminals or affiliates of foreign intelligence agencies. Instead, the voter file break-in was achieved through a so-called SQL injection, a technique that exploits vulnerabilities in the user-facing parts of a website to run unauthorized database commands on behalf of an intruder…

Eddie: Did I get that right, Frank?

Frank Korf, App Developer: Haha, yes, that’s correct.

Eddie: Whew. So tell me a bit about SQL injection. Is this something our clients need to be worried about? Or, what are some of the things we do in our development process to protect against this sort of vulnerability?

Frank: SQL injection is a really classic way to hack into a system. Now, remember, SQL is a language, used to interact with databases (a database being any organized collection of data).

Let’s say you’re collecting information from a form — asking for first name and last name with a button to submit. The assumption is that information will be stored in the database. What someone could do, under the right circumstances, is enter their first name, then put a special character, then list a series of SQL commands. If that form is directly against the database, it would store their first name, but also run whatever commands are listed against the database.

Eddie: So an attacker could use that to pull other information out.

Frank: Yes, they could get other information out, and more. SQL, again, is the only language that interacts with the database, so it’s full access — you can create tables, you can create records, you can destroy things, you can manipulate things. Typically SQL injection is used to pull information out, or to exploit a system to gain deeper access. Records aren’t generally destroyed, because, well… that just historically hasn’t been that common.

So the threat from SQL injection happens when a database is wired directly to front-end forms, or any box a user can type information into, including hidden boxes, because hackers can find those too. Really any information being sent from the client to the server should be sanitized in some way in order to prevent SQL injection.

Here at Earlybird, we build many of our applications with a PHP web framework called Laravel, and more specifically, we use a toolkit inside of Laravel called Eloquent. Now, Eloquent does a lot of things, but what it does mostly for us is sanitize all database inputs, because it acts as a PHP layer between the user-facing portions of an app and the MySQL database. In this sort of setup, we actually write all our commands in PHP and Eloquent writes the corresponding SQL. The beauty of that is, the Eloquent has built-in sanitization rules, so it effectively ensures that all data that we pass through is in fact being sanitized properly.

Eddie: Got it. So it’s about more than just form validation?

Frank: Form validation is extremely important, but isn’t enough to prevent attempts at SQL injection. We do that on the client end, and yes, Eloquent actually does that on the back end, too, so if you try to submit information that isn’t necessary nefarious, but just malformed, incorrect, or otherwise unwanted, Eloquent can let us know that as well.

Eddie: What about projects we might do in JavaScript? I’m guessing there are comparable toolkits in those frameworks as well?

Frank: There are. For projects with Angular.js fronts, we can still use Laravel and Eloquent on the back end, but yeah, modern JavaScript frameworks are offering comparable resources for sanitization.

Eddie: So, overall, SQL injections have a reputation for being a pretty unsophisticated type of attack…

Frank: It is. It’s the easiest one to try, it’s the easiest one to test for. You can throw a number of automated commands, you don’t even have to think about it too hard, you just have to drop a little bit of SQL into a form field, and submit it, and see if it responds — see if the response throws some kind of error. And if you’re a lucky hacker, that error won’t be a PHP error or a form validation error, the server will actually throw a MySQL error, and that’s how you know you’ve gotten in.

We, of course, nip that in the bud by putting several layers in between the form and the actual database. But if you haven’t put those layers in there, it can be really easy to go from a public form field directly into a database.

Eddie: That’s interesting. So to step back, my intention in highlighting this isn’t to pile easy criticism on the Board of Elections — I actually know some technologists down there who are really talented, and like many in the public sector, they’re doing important work with limited resources. But this seems to exemplify the importance of modern practices, or why for some organizations — even those with IT personnel — it might be best to partner with a professional web development operation…

Frank: Yeah, security is historically a difficult subject. Unlike almost anything else, computer security is bailing water out of a boat with a hole in it. It never gets so good that the problem is gone.

The thing about a SQL attack is, unfortunately, a hacker doesn’t need to use the web application they’re trying to steal information from. Once they use a tactic like injection to gain access to a system, they can potentially gain much greater access to other databases in that system, and other pieces of information.

And so saying someone got hacked with a SQL injection attack, it doesn’t even imply it was through their main application or something with their primary focus, it could’ve been some tertiary system, some legacy app they had forgotten about let fall into disarray. Could definitely happen in a place that is understaffed or doesn’t have the resources for a lot of system-wide testing and maintenance. But unfortunately, even that’s enough, because intruders only need one doorway in.

Eddie: Thanks for helping us learn a bit more, Frank.

Frank: Sure thing. This was fun.

Frank Korf is a jack-of-all trades programmer with a decade of digital product experience that ranges from projects in IT infrastructure and financial analysis to work with games and online communities. He holds a Bachelor’s in Computer Information Systems from Bradley University.

Transcript has been slightly modified for length and readability.