Podcast: What Are SQL Injection Attacks?
SQL Injection Attacks are a method for taking advantage of flaws in the way an application is written. In particular, they exploit application vulnerabilities that offer direct access to databases. Mike Shinn, CEO of Atomicorp, has employed SQL injections in cyber security Red Team exercises and built countermeasures that defend against them. In this week’s episode Shinn talks about SQL Injections, the typical vulnerability of databases, the high frequency of the risk and common methods for defending against the attacks.
Atomicorp provides unified workload security for cloud, data center or hybrid platforms. Built on OSSEC, the World’s Leading Open Source Server Protection Platform. See our products.
Podcast Transcript: What Are SQL Injection Attacks?
Bret Kinsella: [00:00:00] This is the Linux Security Podcast Episode 10. Today we talk about SQL injection attacks. What they are and how to defend against them.
Bret Kinsella: [00:00:18] This is the Linux Security Podcast. Welcome back. I’m here with Mike Shinn. CEO of Atomicorp. And today we’re gonna talk about SQL injections. Mike, what is the SQL injection?
Mike Shinn: [00:00:30] SQL injection is a type of attack where an adversary can inject SQL into a program. So for anybody that doesn’t know what SQL is… SQL is a language that databases speak. It’s the means by which underneath all of the logic and everything a program talks to a database. So it’s how a program would ask a database what your address is or what’s the status of a package that’s being shipped to you. So that’s all done under the surface in this Structured Query Language… SQL. And SQL injection attacks are a way of taking advantage of flaws in the way that a program is written. So the way a SQL injection attack works is we just talked about an example of how SQL is used in a program SQL is used to say go find my actions shipping records.
Mike Shinn: [00:01:42] So the thing that’s provided by me, the user, to whatever this program is is my name. Right. So that is a variable in the SQL query and that’s passed into this program and then passed to the database. So the way a SQL injection attack works is that instead of providing the program in this example with my name: Michael Shinn. I put SQL code in there. So this query gets sent to the database and says “Go find every single solitary password for every single user and return it” instead of “Go find Mike Shinn’s shipping history”. So it’s a very powerful attack because it’s a pretty easy mistake for a developer to make there you know. You’re writing a program. You have a variable “Address Name” whatever you pass that into the database as part of a query and the database gives you back the answer you want. So it’s it’s a very easy attack. It’s not hard to do. It’s a very easy mistake to make in the software and databases are generally not internally protected.
Mike Shinn: [00:02:59] That is to say that the database generally doesn’t have a good way to prevent those queries from being successful. A lot of applications are written where the database is treated as just a giant store of information and all the queries are done with the same privileges. So if a query can be successful asking for one thing it’ll be successful asking for something another. So that’s another thing to keep in mind is a lot of databases are typically not set up in a way like maybe like a file system is or you know where there are individual permissions on things it tends to be very one size fits all. So it’s an easy attack to do. It’s really easy to do because it’s… The other thing about SQL is a SQL is in a much as it’s a language it’s not a hard language to understand the queries are you know very easy for a human being to understand. So it’s a it’s not a heart attack to do but it tends to have dramatic effects when it’s successful because once you’re able to make queries to a database you’re generally able to query nearly anything that’s in the database.
Bret Kinsella: [00:04:12] And one of the things we hear about when we do hear about SQL injections a lot of times the target of the attack is like a website.
Mike Shinn: [00:04:20] Yes.
Bret Kinsella: [00:04:21] Some sort of front end cloud hosted software website something that underneath the covers in the database there’s data. People have some interest in.
Mike Shinn: [00:04:31] Yeah that’s that’s a great point. Typically SQL injection attacks because they’re database based attacks that sort of a tendency to think about a database as this thing that’s in the back of the house or behind the firewalls or whatever the case may be it’s something that you know you don’t need to worry about as much from an external attacker. Maybe you think oh this is an internal thing. You know only my internal users can get to it. But effectively every website is driven by a database and just about everything we do these days is through websites. That’s that’s the the way that we as human beings and even the programs that we use on our computers and our phones and and the devices that we have in our houses are generally talking to a website and all of that dynamic stuff at the website sending back to us is is stored in a database and it’s it is the vanishingly small exception that a database rather than a website isn’t somehow backed up by a database. I mean. It’s possible but really nothing any of us I interact with on a daily basis is likely to be that.
Mike Shinn: [00:05:45] So it’s it’s a great way to… for a bad guy to attack things you know Equifax is an example Equifax wasn’t a SQL injection attack but all that stuff was in a database and so they got to it through a website and that’s pretty much the way that things are built these days. There’s a website on the front end and there’s a database on the backend or many databases on the back end.
Bret Kinsella: [00:06:12] So what should people be thinking about in terms of SQL injection in terms of how they need to protect their applications or protect their websites. Are there certain steps they can take?
Mike Shinn: [00:06:26] Yes. So the things that don’t work. We know that they don’t work. And on a preface this by saying it’s not that you shouldn’t do these things it’s that these things will not by themselves protect you. So patching isn’t going to save you from this having awesome programmers isn’t going to save you from this. Having a great software development program that stresses security isn’t going to save you from this because that’s a very easy mistake to make and it’s pretty rare that we are reliant upon software that other people write. So the first thing you have to do is accept the fact that you got something in your enterprise that’s got this vulnerability in it and you don’t know about it. So you need to put active countermeasures in place to be able to detect and block SQL injection attacks in real time. These things are almost the simplest of what I’ll call you know high return attacks that there are these are not things that require a highly skilled attacker to exploit. They’re really trivially easy to do. And the amount of things that I’ve SQL injection vulnerabilities and it is staggering. And they’re published publicly on a daily basis almost on a daily basis. And and that should be a cautionary tale for everyone. So you need active countermeasures for SQL injection.
Bret Kinsella: [00:07:54] What are some examples of active countermeasures?
Mike Shinn: [00:07:56] The most powerful one for SQL injection attacks are Web Application Firewalls really. They’re the most powerful one because this is the most common way the databases are attacked there are tools that are specifically designed to try and protect just the database way down at the database layer. They’re more difficult to set up and configure in some cases. WAFs. Everybody has a WAF. They’re free WAFs at this point. So if you don’t have some kind of a web application firewall protecting your databases through a web based attack from SQL injection attacks the clock is ticking.
Bret Kinsella: [00:08:34] What type of what type of protection is going to be in the WAF? Is are going to be like a rule that says these certain parameters can’t be can’t be utilized. Or…
Mike Shinn: [00:08:43] Yeah. So a WAF is is going to give you… there’s two non mutually exclusive ways that a WAF can protect you from a single injection attack. One is what you describe where a WAF understands what a SQL injection attack looks like. Will detect that those attacks are occurring and will block them. In other words the WAF understands what a bad thing looks like the other way that a WAF can be set up which is not mutually exclusive to what I just described is the WAF can be setup to understand what good things look like. So if the input for example to the hypothetical I gave earlier my name Mike Shinn contains anything other than you know the letters A through Z and a space you know… block that. The problem with SQL injection attacks though is SQL injection attacks are plain English so it’s not really a bunch of you know cool look. You know it’s it’s it’s more challenging to detect them so you need something that typically knows what SQL looks like trying to just limit the input to something that’s known good. In the case of SQL injection attacks is much harder to do particularly when you have alphanumeric input you know regular human words. It’s it’s challenging to take that approach. So the the the more practical approach or SQL injection attacks is what you described earlier which is to have rules that describe what SQL looks like to detect that it’s SQL and to block it where it doesn’t belong.
Bret Kinsella: [00:10:24] That sounds great. Mike, thank you so much for sharing your insight on SQL injections.
Mike Shinn: [00:10:28] Always a pleasure.
Atomicorp provides unified workload security for cloud, data center or hybrid platforms. Built on OSSEC, the World’s Leading Open Source Server Protection Platform. See our products.