We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

The Mike Rothman Security Report

Peter Schooff

Number One Threat to Web Applications: Mike Talks SQL Injection With White Hat Security

user-pic
Vote 0 Votes

In this month's Mike Rothman Security Report, Mike and Jeremiah Grossman of White Hat Security take a deep dive into an application attack called SQL*Injection. This scourge is responsible for the mass, automated attacks that have been found compromising hundreds of thousands of websites over the past few weeks.

Jeremiah explains SQL*Injection and then makes some clear recommendations on how to deal with the attack, especially for those developers still responsible for first generation web applications on platforms like .ASP, early Java, and PHP.

As always, Mike also puts Jeremiah through the free association ringer and gets his views on hot topics like developers attempts to write secure code, OWASP, and source code analysis.

Listen to or download the 10:32 minute podcast below:



Download file

MR: Hello, this is Mike Rothman. Welcome back to the Mike Rothman Security Report here on the ebizQ Network. This month we are going to take a bit of a deep dive into an attack called "SQL Injection". That's right SQL Injection. Basically, how a lot of web applications are attacked at the database level. And I am so pleased to be able to welcome my friend, Jeremiah Grossman from WhiteHat Security to basically kind of walk us through a number of these different issues that are happening every day from a SQL Injection standpoint. Jeremiah, are you there bud?

JG: I'm here. Hi Mike, how are you doing? Thanks for having me.

MR: I'm doing great. So why don't you just tell us a little bit about you, Jeremiah as well your company and then we'll jump right into the content.

JG: Sure. I'm the Founder and CTO of WhiteHat Security. I've been in business for seven years. We provide an outsourced website vulnerability assessment and management business. Our customers subscribe to our service or subscribe their websites to our service, I should say. And day in and day out, week in and week out we look for the vulnerabilities on their site, let them know where they are so they can fix them and, hopefully, before the bad guys exploit them.

MR: Yep, that's great. That's great. And obviously, we see anybody that's paying any kind of attention to pretty much anything can certainly see that SQL Injection is still really a major scourge on the whole web application scene. So why don't you walk us through a little bit about what SQL Injection is and why it's still a problem. Right. I mean we've been dealing with this stuff for four or five years and we still have tens of thousands, hundreds of thousands of websites that are still vulnerable to this kind of attack. So I mean what's the deal with that?

JG: Oh yes, that's the thing. So SQL Injections are one of the 24 known classes of attack that we have to be worried about on a website. And it's actually been about let's see nine or so years since we've dealing with this but really more so in the last four to five since the bad guys have learned how to exploit it. And what SQL Injection is, it's when somebody from the outside can send traffic to your website, Meta characters and different things.

Usually, just using a web browser and can start controlling your database from an outside point of view. And essentially, when you're pulling credit card numbers out of your database or doing login, they can actually append statements into the web request, again, right, using their browser and make your database do things other than what it was intended such as give up all its credit card numbers, drop tables, and other nasty things like that.

MR: Yeah, so lets kind of dig into a little bit since that would seem to be a huge issue. So basically, SQL Injection attack allows an attacker to basically drop tables, can actually change data, or they're able to access some of the private data that really resides within those backend databases; is that how this application or attack works?

JG: Exactly. Whatever the backend web application can do, the bad guy can now do. They're piggybacking on its permissions.

MR: Okay. As my youngest daughter who is starting to learn a little bit of Spanish at four years old can say, "No es bueno" on that. That's obviously that's no good from that perspective. So if you could kind of just give a feel for maybe two or three things that some of the listeners out there could focus on, I think that would pretty helpful for them in terms of just eliminating this whole or at least controlling some of the SQL Injection problems that we're dealing with.

JG: Sure. So you asked a moment ago why we still deem this as a problem. And so there's actually two different types of websites out there. There's the old websites and there's the new websites. The old websites built on older technology and older languages. They're going to be -- they didn't have a whole lot of protections built into the frameworks and thus, they're going to have a lot of SQL Injection vulnerabilities in them.

And when you look at some of the mass SQL Injection attacks that have been happening in the last couple of weeks, they're mostly targeted at those types of websites, the ones with the older technologies, older programming languages, and they make for easy pickings.

MR: Yes, so such as Active Server Pages and maybe some of the first generation Java stuff. Is that what you're talking about?

JG: First generation Java, ASP classic, older PHP, absolutely. The operating system doesn't matter so much; it's just the applications built on top.

Anything more recent, Dot Net, a lot of the J2EE stuff, Rails, they're not immune to SQL Injection but there's a lot less of SQL Injection problems natively. Now, that's where we get to talk about solutions. The reason that the older websites are more prone to these issues versus the newer sites is that the newer websites are using what's called "prepared statements" or "parameterized SQL statements".

And the reason this works is there's no concatenating of SQL statements, building complex SQL statements. Everything's abstracted and the developers, let's say, helped to doing the easy thing is also the secure thing at the same and they're not a vulnerable as they were before so that's one of the ways. Another way, and you'll hear this bantered about all over the place.

As a matter [0:05:14] SQL Injection or something else like is a strong input validation that the developer make sure that they don't use what they don't expect to receive. Making sure that the data that they're getting from the untrusted user because you never know who it's going to be, is what you expected to be, the right characters, the right format, nothing malicious about it and only then is it safe to use.

MR: Yep. Yep. So those are some good ideas. Now, let's says how do you figure out that you're actually vulnerable to this kind of thing? Is it something that you wait for your customer to poke you in the eye about or is it something a little bit more proactive that you can do to identify a problem and then obviously fix it?

JG: Well, the best-case scenario is want to find it before the bad guys do but that's really, unfortunately, that's not the only way. An outsider can point it out to you maybe in conjunction with the press or you can be on the wall of shame with the other hundreds of thousands of people out there that are getting their databases exploited right now. But should you want to find this proactively whether before or after you release the code, you might contract with a company like WhiteHat and to assess the website for security purposes and go do I have this, it's in my website, and if I do, how do I fix it.

MR: Yep, and you guys, obviously, that's what you do a good portion of your day. This is one of the 24 types of attacks that you deal with from a web application standpoint so that's certainly an option for customers that just don't want to deal with this kind of thing. So what are some of the advantages of working with an outsource provider or managed provider as opposed to just getting a scanner and doing it themselves?

JG: One [0:06:51] you can get scanner and scanners are great tools but a tool like any other tool requires a good user, an intelligent users to drive these things. So if you're not a web security expert, the amount of value you're going to get out of it is suspect. So when you go with an outsource firm, we can play the ROI all day long but you get an outsource security expert and this is what we do day in and day out. You get an independent third party view of what's going on there. And the other benefit is that you don't have to hire people, you don't have to train them, you don't have web security experts, you're free to just to go about your business and go build your applications as you see fit and leave the security to those who do this every day.

MR: You bet. That's great, Jeremiah. Listen, I think that gives our listeners a little bit of a background on SQL Injection. Certainly, some good feedback on the things that they have to look for, especially, if they're using a number of those older platforms and frameworks to build their web applications on. So now, let's kind of transition into, certainly, my favorite part of the show, which is the free association part. I explained just a little bit to you but what I'll do is I'll blurt out a little bit in terms of a couple of statements and just right off the top of your head one or two sentences of that stuff.

JG: You're going to mess with me aren't you? I know you're just waiting for this.

MR: I am. And that's why this is my favorite part of the show because I do get to mess with folks. So let's go, free association. So give one or two sentences on developer's ability to build secure applications.

JG: Developers ability to build secure apps, good for today not for tomorrow.

MR: Because?

JG: New attacks are coming out all the time. You can only secure code against the things you know about today, but once it goes into production, given long enough timeline we will find ways to attack it that's why the web is so unsecure right now.

MR: You bet. Next one, OWASP.

JG: Oh, a good one. OWASP, good repository for getting information about how to develop secure code for the things we know about today.

MR: That's great. Just a little plug for Jeremiah. He's one of the originators as well as a big contributor to the OWASP Top 10 attack format and as well as just a lot of the great work that the OWASP guys are doing out there to really educate the next generation of web developers so that they can build security a little bit better. And let's wrap up with source code analysis. What do you think of source code analysis?

JG: Oh man, you're hitting me with all the hard ones. Let's see here. Millions and millions of lines of source code. We're not going to get through it all at once, we have to take it off in little chunks. It's best to be automated because no one can ever get through it all line by line.

MR: But I would also add probably not a panacea in terms of helping people to develop source code or secure source code. Is that a fair assessment?

JG: Yeah, I mean everything's going to be a tool to incrementally improve security. This is security, nothing's a silver bullet. Just inching things hard and that's actually our biggest challenge in security. I see as we have a hard time measuring the benefits of our security solutions and how far we push the bar. That's why I like Black Box testing the best because we can actually see what the bad guy's actually capable of independently.

MR: Yep, yep, that's great. Listen, I want to thank Jeremiah Grossman from WhiteHat Security. Great information that you gave to folks. Hey Jeremiah, if people if want to find WhiteHat out on the web, how do they do that?

JG: How do they find WhiteHat on the web? Go to www.whitehatsec.com and there's a mountain of information there, mostly web security related in you can imagine that.

MR: You bet. www.Whitehatsec.com. Once again, thank you Jeremiah. Thank you everybody for listening. This is Mike Rothman and once again for the Mike Rothman Security Report here on ebizQ Network. We are out.

ebizQ is proud to bring you Security Incite's Mike Rothman, who podcasts and writes on application security and related topics.

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT