Mike also gives himself the "free association" treatment, discussing topics like Facebook and the impact of Web 2.0 on PCI.

Listen to or download the 11:39 minute podcast below:

Download file

---Transcript---

Hi, welcome back to the Mike Rothman Security Report here on the ebizQ Network. This month I'm actually going to fly solo because our topic to talk about is Web 2.0 Security and really the application issues and application risks that we face as a revolt of these Web 2.0 types of applications and what kind of risks and what kind of threats.

Basically how many different ways can we get compromised and slammed by our social networking types of applications in this penchant that everybody has to share information about themselves so that's what we're going to talk about here this month.

And I think it’s actually a pretty timely type of discussion for a lot of reasons. And one, I mean, I’m sure many of you that listen to the podcasts on ebizQ tend to be corporate types and that means that somewhere in your organization somewhere bubbling up is the need to use applications like MySpace, like Facebook, like maybe LinkedIn to really start to build communities around your business, right.

Maybe you have some bloggers that are internally writing about what it is that you do, talking, getting involved in the conversation trying to figure out from a thought leadership standpoint how you can present whatever it is that you do in the best possible light.

Well, any time you use that code word called “user generated content�, that means you have some type of security risk. And why? It's because a lot of these applications that are being built and that are being put in place by nowadays allow users to basically add if they’re not websites and certainly content to your site.

And whatever they can basically fill out a form and input information that can be seen by other people that gives them the opportunity to basically compromise your site if you're not careful. So what we're going to do this month is talk a little bit about the risk, talk a little bit about the threat vectors that we have to deal with, or the attack vectors that we have to deal with.

And then next month, I'll have another guest to be determined, it’s a surprise, to really talk about a lot of the defensive aspects of Web 2.0 that we are starting to see emerge. So when we think about the risks, what I can say is that they’re not a lot different than what it is that we’re dealing with when you're talking about general application types of security, or even more generic information security.

We’ve got malware as a risk, malicious code that folks are implementing either by adding images that are compromised, adding scripts into your comment fields that anybody that renders the web page then gets compromise because script obviously runs code in somebody else's browser. We got drive-by downloads.

Again, these are types of data that would be input into your website that then, again, downloads some type of malicious code to the visitor whenever they show up. Again, we’ve seen a lot of different applications that have been vulnerable to this kind of thing whether it's any of the blogging networks or something like MySpace or even Facebook.

We have spam. Obviously, the spammers are out in force and they're doing a couple of things. The spammers are really 1) about getting their message out whatever it is that they're pushing but 2) they’re also again trying to implement and integrated malicious code into your site. So if you get a friend requests from somebody that you don't know who they are, in many cases there could be something compromised or something malicious about the intent of that type of friend requests so we have to be careful about that.

We got data leakage. Obviously, folks are sharing more and more of their reality, more and more of whatever it is that they do out on these networks. And of course, if we just look back to Governor Palin here in the United States, the vice presidential candidate, she had her Yahoo mail compromised because of basically some information that she shared out there.

And obviously, she’s a public figure and people did all sorts of digging to figure out what she was about but that information was used to compromise her specific information out on the network, used that to get into her e-mail and then create all sorts of havoc.

The whole data leakage thing is really related to targeted attacks. This is another thing that we're starting to see a lot more of, especially, when you think about the individuality of something like Facebook, something like MySpace because what that does is it allows somebody to target, for instance, a high net worth individual.

Maybe you get a friend request from somebody that you knew. Well, how do you know them? Well, because maybe you published somewhere that you went out with Bob and you had a great time at the ball game or something like that. Well, amazingly enough maybe Bob sends you a friend request. But it's not Bob its actually Andres who happens to be in Estonia who is trying to use that information to friend you to be able to compromise your specific environment, or send you an e-mail that says hey, I know all about your mortgage that is having problems because you are a customer of Wachovia, for example.

Maybe you're a little concerned because of the Citigroup acquisition. Again, there are a lots of different ways to find information about you that can be used within the targeted attack that is again somewhat unique to Web 2.0 just because you are sharing a lot more information out there. We got traditional application attacks or another way Web 2.0 applications can be compromised.

And these are the cross-site scripting attacks, the cross-site request forgery attacks outspoken about at length on previous editions of the Mike Rothman Security Report so you may want to go back, search the archives at the ebizQ Network and check out those posts and those podcast.

Because, again, I do some introductory types of information about those specific attacks but those are very much in play when you talk about Web 2.0 because again they’re typically application attacks from that perspective so we're not able to get out from underneath a lot of those very specific types of application attacks.

And finally, there's the whole thing of social engineering, right. Again, its still back to praying on the gullibility of many of the users out there. You send them a mess saying hey, click on this thing its really funny, or click on this thing Bin Ladin’s been captured, or click on this thing the bailout in the United States didn't go through. And low and behold, you go to a web site that then renders some code because it's been uploaded to this Web 2.0 site and you’re compromised from that standpoint.

So all these things are still in play, still in very much a problem from the standpoint of Web 2.0. So again, what’s the impact here, right? We all know the world's a problem. We all know that, basically, we’re kind of screwed from the standpoint of what it is that we're doing relative to protecting ourselves fro Web 2.0. Again, next month we’re going to talk a little bit about these specific defenses, but in general, we have to be aware.

In general, we have to be testing our applications to make sure that we are using and understanding what specific vulnerabilities, what specific exploit paths are actually available to the specific applications. Because again, if you don't even know what's vulnerable, if you don't know how you can be compromised, how are you going to fix it.

So again, I'm a big fan of testing our application. I'm a big fan of penetration testing. I'm a big fan of application scanners because again, I believe it’s very important to know what is vulnerable from the standpoint of your specific application. Again, I don't think a lot of these problems are going to go away anytime soon because there's still a huge; a huge economic incentive for the bad guys to continue to do what it is that they're doing.

So again, I think the problem is going to get worse before it gets better. I wanted to this month really talk a little bit about these specific attack vectors that we’re dealing with as opposed to next month when we start talking about solutions so I'll put you on hold a little bit from that standpoint. Sorry about that but again in a 10-minute podcast I can't really go through both in one specific session.

We’ll have a great guest next month so that's kind of main session. But what also want to do is maybe do a little bit of free association on myself because this is really one of those things where God I put everybody else through free association maybe I should do it myself.

So okay, I'll try to be schizophrenic a little bit here and out of one side of my brain blurt out a topic something like Facebook and then out of the side of my brain I'll have to respond in basically a paragraph or two. And in general, Facebook is one of these things that you kind of have to be involved in because a lot of your customers, a lot of your users, a lot of your employees are involved in this.

And again, its one of these places that's kind the a festering pit of malware right now. It doesn't really that high profile an issue because nothing truly malicious has really happened on Facebook but I think that's a matter of time. So I am cautiously skeptical that we’ll be able continue to escape some massive Facebook type of either privacy or data leakage type of thing so watch this space from that standpoint.

And the other thing, my next free association topic, let’s say PCI, right. So a lot of folks are vulnerable or a have to be compliant with PCI regulations. If you collect credit cards, how does Web 2.0 impact PCI? Well basically, again, a lot of it just gets back to the same ideas that I was not about earlier on in the podcast. Web 2.0 its interesting but it’s not necessarily that different from what it is that we've done before.

Part of PCI is to do web application testing, it’s to do maybe build your applications using a secure development life cycle, maybe is to build your specific environment and use a web application firewall to protect those applications. So those are things that can apply to Web 2.0 applications just as they can any other web application. So to me PCI, again, it’s just more the same from that standpoint.

So with that, I want to thank you for your time and your attention. I want to once again thank you my host for the Mike Rothman Security Report, myself. And also, thank the ebizQ Network who are so kind and gracious to give me a forum to basically babble about all the things that I think are important. So we'll see you next month when we talk a little bit more about Web 2.0 defenses. And until then this is Mike Rothman. Be well.

In the Free Association section of the show, Mike gets Ted's ideas on PCI (overblown, way too complicated), as well as the security implications of SaaS (software as a service), which presents a big issue as shared data (in shared databases) continues to become a prevalent deployment model.

Listen to or download the 17:23 minute podcast below:

Download file

---Transcript---

MR: Hi, this is Mike Rothman and welcome back to the Mike Rothman Security Report here on the ebizQ Network. This month we’ve got another great quest. Another very timely and important topic to discuss relatively to application security concepts. So this month we’re going to be talking about database security.

And if any of you have read my feature articles on ebizQ, or listened to any of the report podcasts, you know that applications and web applications specifically tend to be really the lowest hanging fruit. So its 85, 90, whatever the number is percent of attacks nowadays are really focused at the application layer and they’re not doing it because they think its cool to break into web applications.

They’re doing it because the web applications are really the front to the database and that’s really, where a lot of the action is from that standpoint. So to talk about this topic, this month I’ve gotten a friend of mine called Ted Julian here on the show to help us really understand about database security and really why its important. Ted, are you there man?

TJ: I am here.

MR: That’s great. So Ted, why don’t you just kind of introduce yourself and talk a little bit about your company before we kind of jump into the nuances of database security.

TJ: Yeah, I’d be happy to. The funny thing in and is and frankly the pleasure to do a podcast here with you Mike is that we have such a similar background, right?

MR: Yeah, don’t admit that publically.

TJ: Yeah, I know. I just shot my credibility entirely. Both sort of formal analysts and both taking a try at, at actually doing something in terms of getting involved with some security technology and trying to get some businesses going there. So that’s the quick bit about my background.

I sort of wound up here at Application Security as part of a series of security startups. What we do here is database security. So in a nutshell, we help our little over a thousand customers extend the security best practices that they’ve deployed over the last ten years on their networks, and their purpose hosts, and we help them extend that to the databases where a lot of their mission critical data sits. We do that with our DbProtect suite of software.

MR: Great and that’s a good introduction. So lets talk a little bit about database security. So obviously, there are a lot of different analogies that we could use to the network side of things. So if there a kind of categorization of different functions that we think about from a database security standpoint that would help the listeners really start to get their arms around what is this mythical thing called database security.

TJ: Yeah. Yeah. Well, I think as we saw in other ways of security in the early days a lot of people hoped there might be as simple as encryption, right. Hey, if we just encrypt that sensitive data in the database then we’re good. They can't run off with it. And that is a leg on the stool but I think as a lot of people have learned probably over the last five years or so, there’s never really that much of a shortcut or that easy of silver bullet to solve the problems.

So really its extending that best practice. Vulnerability management is maybe one model to think about starting with a discovery in terms of where is your sensitive data. What databases does it live in that sort of thing? Because its once you’ve that that you can start thinking about well, where might we want to do encryption or what role might vulnerability assessment play in that, or are there databases where we want to be able to monitor activity, look for what the privilege users are doing depending on our security and compliance requirements.

MR: So if we think about it, obviously, one of the things that I think is interesting is that a lot of security technologies really start at the scanning level, right, which is I don’t know what I don’t know. So let me figure out, yeah, do I have some configuration issues, do I have some other problems so you tend to look at it from a scanning standpoint.

And then once you kind of got your arms around that, then you want to do some additional whether its remediation, whether its more detailed monitoring types of aspects -- that so you’re getting deeper into it and ultimately maybe you want to do some intrusion prevention or some other type of specific blocking behavior types of aspects. And it is just funny and both of us have been in this space for so long you see the same kind of adoption models and mentalities repeat itself over and over again.

TJ: Well, I think that’s the good news, right, is that if you’re an application developer and you’re looking at this problem, maybe you haven’t had to think about some these security issues before. And the good news is that you may not be familiar with them but these models exist and the developers, the DBAs absolutely have to be involved to figure out how to actually map this to the infrastructure that they know and love and own.

So they don’t have to make something up from scratch. And better still, by leveraging these models, they’re going to find that everything falls into place with the company’s broader’s security and compliance efforts. And as a result, whatever technology they deploy or whatever process they put in place, can likely very easily connect with stuff that the company has already been doing for ten years or more but just in other parts of their infrastructure.

And that just increases the likelihood of success that if you stick your neck to try to bring security to this infrastructure that you own, that whatever resource you throw at, people, products that you might buy, or whatever is going to have a greater likelihood of success and if you can pull that off, what an opportunity.

I mean you look at you and I, right, and being in this industry what happened to sort of these network management or network architect types who sort of brought security to the network, those guys really made a great career for themselves in doing that. And the exact same opportunity is there for people at the application stack now whether you’re a developer or DBA. To the be the guy that brought security to the crown jewels where the data lives is a pretty powerful and compelling thing to do for your career.

MR: Yeah, I think that’s a great point both from career development standpoint. I do think that there are a little bit of contrast in terms. In the good old days, right, a security person could largely operate kind of standalone. Yeah, they had to at least grunt at the guy that was in charge of the routers because you had firewall and right behind the router but beyond that a lot of the perimeter defenses it really could be a standalone. I think we really seeing a difference with the database space as well just applications in general in that it really requires a cross functional context -- within the IT organization.

So again, the application developers, again, you snarl at the DBAs because they tell you can't do all these things and the code and queries that you want to write just aren’t efficient for what they want to do and how they want to manage data. But at the end of the day when we’re thinking about protecting all this stuff, it becomes all the more critical that we’re all on the same page and we’re all working together because again, attackers have a wonderful way of finding the weakest link in the chain -- and they use that to pretty much make everybody miserable.

TJ: That’s true. Things are a lot more complex. They’re going to need to work across functions and other good news/bad news too is compliance, right. So by extending your control framework to this the new part of the infrastructure, great news, you can ground your security stuff where the data lives, you can ground your compliance efforts where the data lives, that’s very compelling. Career opportunity like we discussed.

Definitely a budgetary opportunity. CFOs can be pretty tough but I think the argument of grounding security and compliance and the databases where all the customer data lives or whatever the mandate might be. That’s kind of pretty strong argument but it does increase the stakes you’re right because not only is it more complicated, more people are watching and people can go to jail like appliance side, the breach side, whatever.

MR: You bet; the old perp walker or the customer disclosure. There aren’t too many days that are worst for a security person or even application person or anybody than when the CFO or the CEO get walked downstairs in handcuffs. Obviously, that’s the imagine that sear to a lot of folk’s minds. And obviously we haven't had that in a little while but we really have to remember that there is a lot at stake in terms of what we’re doing.

So that old adage of lets keep in mind that the enemy for the most is not necessarily inside the walls of this enterprise and a lot of folks kind of forget that. They get into these internecine kind of IT political kind of battles -- to me its like silly, right. So obviously, we go to do a lot of monitoring on the database because there are insiders threats, there are separations of duty -- requirements and that’s clearly something but we keep our eyes -- if you spend too much time kind of fighting battles insides, you’re going to forget that the real battle’s outside.

TJ: Right. And that too gets back to this process thing we were talking about starting with the discovery and figuring out what your posture and then going from there. Because the last thing you want in this environment that we’re describing is to sell management a bill of goods about whatever it might be encryption, or just assessment, or just monitoring, or what have you and then there’s a breach and low and behold it’s a database you didn’t even know existed or you weren’t really doing anything about. You do not want to be in that position. So its best to take a methodical approach and make sure that your prioritizing your efforts in accordance with either your risk or business requirements.

MR: Yep, you bet. That’s great. So Ted, as we kind of wrap up on the first section, is there something as folks are starting to dip their toes in the water and try to figure out how they should be getting their arms around this whole idea of database security, what are maybe one or two of the things that you’ve seen customers kind of screw up, right. If there’s a couple of things say, don’t do this right, I’ve seen this movie and it’s a pretty horrible ending if you kind of go down this path. Are there one or two things you could point out that I think would be helpful for the listeners?

TJ: Yeah, definitely. Leaping to encryption is one. It’s a leg on the stool. Its going to be something that most people will want to consider. So for example, if you’re a retailer encrypting cardholder data, its definitely on the list and its very important. But its hard. Its going to take you a fair amount of time to figure out how to do that in a way that is both sound from a security perspective but also is not going to be disruptive from either a performance, or availability, or breaking your apps perspective.

And there’s a lot practical considerations there, which is if it takes you a year or more to get this done, you’re not showing any ROI to the business. Forget potentially missing important databases that might have needed, right. So hereto, we kind of come back to assessment being just a great way to get started. Because within a day or two, frankly, you can start to learn stuff, and you can start to fix issues, and you can to have that dialogue with management, build up that trust, show that you’re on the case, and that has many, many benefits in terms of helping you justify staff, helping you justify budget for buying different technology.

Like I said, helping you build up that trust so that God forbid there’s a breach, God forbid there’s a serious audit finding. Instead of the conversation starting with you guys were totally asleep at the wheel, its like, no, we’ve seen the reports you’ve been giving us every month. We know you guys are on this, so lets figure out about what we need to do. That, I think is really practical advice. Its not the sexiest technology whatsoever but those reports are like gold for those reasons.

MR: That’s great. So, hey, just to kind of wrap on our first section. You know the database is really, where a lot of the action is because that’s where the private data that regulations like PCI are worried about, that’s what the attackers are going after. So again, its certainly something I think every application developer needs to familiarize themselves with in terms of how are they going to protect the data that they’re gathering at the application layer.

And obviously every security professional needs to start understanding how the database whether its assessment, monitoring, remediation, blocking or ultimately encryption is really another layer in a structured defense in-depth model that really builds a number of different controls to protect your data at every layer where it could potentially be accessed by criminals and potentially insiders.

So that’s a great overview so let’s kind of transition a little bit into the free association part of the show. Where obviously, I think its great we get to get a feel for what everybody’s thinking really off the top of their head. So you know the rules, Ted. Basically, what we need to do is I’ll throw something out there and then a breath or two just kind of shoot off the first thing that comes to your mind. So let's start with PCI.

TJ: Troubled, wayward, lost...I don't know.

MR: Yeah. Maybe a little more becoming more complicated than it needs to be.

TJ: We had an opportunity with PCI to do something that was both prescriptive but also really focused and achievable and I think we’ve blown it. What does anti-virus have to do with protecting cardholder data? I mean there’s a linkage but its pretty far removed.

MR: Right. Right. Right. More like kind of Baseline Security 101 than anything else.

TJ: Yeah, I mean, I think with the best of intentions, a group of people, the credit card companies and so on, tried to come up with a fairly all-inclusive list to be complete. And in hindsight, I just think that was huge mistake because its now just so unwieldy that its hard for them to make progress.

MR: Yep. So next topic. Let’s talk about Software-as-a-Service and the security implications of that.

TJ: The elephant in the room. The slumbering giant. I don’t even think we begun to understand what the security issues are there.

MR: Well, I agree with that and I also think its kind of interesting from a database security standpoint because, obviously, when you start to centralize or build out a multi tenant oriented environment, it becomes even that much more important that you’re tracking, you monitor, that you understand who’s accessing which data and that they’re both authenticated strongly as well as authorized to do so. Of course, that’s one man’s opinion.

TJ: No, no, well, its interesting Mike, right, because we get asked pretty regularly about virtualization. What does that mean for database security and how soon will customers start to virtualize database and that sort of thing? And that, I think, it’ll happen but I think it’s a much longer term issue.

I think there’s some serious hurdles to clear before people will start doing that. Software-as-a-Service; however, I mean that is going on right now big time and there really is very little discussion about what does it mean that whatever the service might be, something like Salesforce what have you has a big databases, a bunch of little databases.

However it is, their architect to them wants the separation of rules between the users, the administrators internally, the administrators within Salesforce. What are they doing to secure a breach from the outside that impacts one user of that service spilling over into others users? I mean nobody’s talking about that stuff.

MR: Yet! Hopefully, again, guys like us can evangelize a little bit due to the fact that, again, hey, its compelling as a deployment option as it is. We really have to be careful because there are some considerations that don’t necessarily map to the physical world--

TJ: --And the bad guys have got to be thinking about this. I mean there’s a gold mine in some of these applications.

MR: You bet. So Ted why don’t you tell everybody how to get in touch with you guys at Application Security.

TJ: Easy. www.appsecinc.com. So that’s www.A-P-P-S-E-C-I-N-C.com.

MR: Great. So obviously up on the AppSec can learn all about database security as well as get access to a bunch of Ted’s ramblings. I know he has a blog now so they’re joining the blogosphere, as well as a bunch of webcasts and white papers and all that.

TJ: Right. And we’ve got a free version of the scanning module that includes discoveries. So even if you don’t buy a lick of software from us you’d be well advised to grab AppDetective Pro if only just to figure out what databases you got and start to figure out what their posture is. I don’t think you could go wrong doing that.

MR: You bet. That’s a great idea. So with that, I want to thank Ted Julian from Application Security Incorporated for being our guest this month. So again, thank you Ted, I appreciate the help.

TJ: Its my pleasure, Mike, thank you.

MR: All right. And that wraps up another episode of the Mike Rothman Security Report here on ebizQ Network. Everybody have a great month and we’ll be back with another timely rant from me and one of my pals next month. We’re out.

In the free association section, Nitesh rails on PCI a bit, as well as talk about how the Black Hat conference has changed and why he takes time out of his busy schedule to attend every year.

Listen to or download the 18:20 minute podcast below:

Download file

---Transcript---

MR: Hello everybody, this is Mike Rothman. Welcome back to the latest edition of the Mike Rothman Security Report here on the ebizQ Network. This month we are going to tackle the devious and nefarious Cross-Site Request Forgery attack, otherwise known as CSRF.

I have enlisted a good friend as well as a well-regarded security researcher named Nitesh Dhanjani to come on and be a guest on the show this month to really talk about CSRF, talk about why it’s a pretty nasty attack, and also what developers can do to really protector their environment against this type of attack vector. So let’s check in. Nitesh, are you there buddy?

ND: I’m here. Thanks for having me.

MR: That’s great, Nitesh. So why don’t you just kind of give everybody an idea about who you are, who you work for, as well as some of the things that you’ve done just so people can have an understanding about kind of what you’ve done in the past.

ND: Sure. I’m Senoir Manager at Ernst & Young’s IT Enablement Practice. My job is to help E&Y’s client build, install solid security and IT solutions. And my job is also to make sure that E&Y’s current services are cutting edge and to incubate new service lines when it makes sense.

For the purpose of this discussion, we talk a little bit more about how I’ve been involved with application security a little more with emphasis on Web application security. My core job responsibility here at E&Y is to lead our application security efforts from helping clients understand how to relate apps and goals to their overarching enterprise wide security strategy to helping them develop a roadmap to increase their capability, all the way to tactical processes and best practices, application portfolio management, methodologies for attack and penetration threat modeling, source code security reviews, training and metrics.

I’m personally fond of application security because of the huge attack surfaces applications have. A typical large sized internet facing application has a couple million lines of code and a single bug can allow somebody with just a Web browser to steal intellectual property and cause havoc.

I’m also particularly fond of application security because it’s a key point where the business and technology intersect. And some of the intelligent CIO’s understand this and leverage this to their advantage to kind of lend appreciation from the business, which is key because security is often perceived as an expense account.

So besides my job at E&Y, I blog at the O’Reilly. I’ve written two books and I’m thinking of doing one more. I like to speak at conferences and that sort of a thing.

MR: Thank you Nitesh. That’s a great overview. And I also do want to point out our guest’s modesty as well. Nitesh is one of most highly regarded application security experts out there. He’s the one that worked on the Safari corporate bombing attack, which was a huge exploit that was uncovered about Apple’s Windows based Safari browser.

So Nitesh is not only an expert but he’s also a modest dude. So welcome to the show. Let’s kind of jump right in and talk a little bit about Cross-Site Request Forgery. So if you just take the listeners through a little bit of an idea about how the attack works and why it’s pretty dangerous I think that would be a great way to start things off.

ND: Okay. Sure. I’d be glad to. Cross-Site Request Forgery is really an attack against the Web browser and the user. So before we kind of dive into that, let’s go back to the early stages of the World Wide Web. Now, HTML is something that allows you to link and include resources from different locations and that is a core design principle of the Web, that’s how it’s designed to work.

For example, my Web page can just have your browser display an image that is really hosted on someones else's server. This is the World Wide Web by design. So you keep that in mind. And now let’s take upon a scenario. Let’s say you’re logged into your bank account online and the Web application that your bank uses is -- lets consider -- let’s assume that is one about the Cross-Site Request Forgery.

Now, lets assume that you log on to this bank account, this application and you stay logged on and you open up another browser tab or another browser window and you browse to a malicious site. This malicious site can now abuse your browser to by way of Cross-Site Request Forgery into making your browser perform a money transfer transaction on your banking applications that you did not authorize or intend.

This really explains the real world scenario and illustrates the impact of Cross-Site Request Forgery. So before we talk about what just happened, let’s talk about the design of the application first. Consider that this banking site that we’re talking about had a section called money transfer consisting of simple form you fill out that asks you for the amount you want to transfer and the account number you want to transfer the amount to.

You fill out that information, click on submit and that’s how it’s supposed to work. The browser then connects to the Web server, issues a post request because it’s the form to its particular URL, which is then parsed by the application and computed. That’s really poor logic. You have simple Web application, a simple form, straightforward.

Now, since this application that we were talking about, the Web application for the bank was susceptible to Cross-Site Request Forgery, here’s what really happened. When the victim logged into the bank application and opened another browser window and browser through the malicious site, the malicious site simply all it did was served up an HTML form that had the account number and the amount they want to transfer hard coded into the form and used Java Script to submit the form to the Web application URL.

So what really happened is from the perspective of the banking Web application, the incoming request that came in looked exactly like the request that would have come in if the victim had legitimately performed the transaction. So that is really Cross-Site Request Forgery. Cross-Site meaning from a malicious site to the victim’s site and request forgery meaning a request or a transaction that the victim did not need to execute.

MR: Right. So let me get this straight. So basically, I could be on --I’m just doing my business, right. Whether it’s on Gmail, or a banking account, or something else. I open up another tab which I think everybody does, right.

ND: Yes.

MR: I tend to have five or six different tabs open on a slow day, right. So I open up a different tab. That tab opens and goes to a malicious Website, which then launches an attack against my bank or my Gmail site, which is actually accepted by that site because it thinks it’s me. Is that how this thing works?

ND: Exactly. And because you’re already logged in, the malicious site submits to the same URL that your legitimate application would if you performed the transaction. Your browser will go ahead and send the right cookies and everything because what is the browser? The browser thinks, well, I have established a session to the domain. I have a cookie for this domain and I’m sending a request to this domain.

I’m going to send to the session ID and the request. Of course, one to note is unless the malicious site has abused Cross-Site scripting as well, which -- let’s assume it has not just to keep things simple. The malicious site in this case, well in most cases, depending on how things are. In most cases, will not ever get to even see the result of what just happened but too late the damage has already been done.

MR: Right. So and the user or the browser never knows anything happened. So it’s totally transparent to both the user as well as the malicious site?

ND: Exactly. And the key thing here is even if you are the victim Web application owner, and you look at your logs, the IP addresses you will see will be your customer’s IP address.

The thing you might be able to perhaps in some cases kind of figure out which malicious site is doing this is by looking at the referrer tags. So from a perspective of instant response, that’s sometimes you may uncover some information of what are the malicious sites that have abused Cross-Site Request Forgery on my application.

MR: Right. Wow. So if you’re the Website owner, obviously, trying to protect your customers against something like this, what are a couple of different techniques that you could use on your site to make sure that a malicious site doesn’t or is enabled to perform some type of CSRF attack against you?

ND: The key is to be able to differentiate somehow between -- its supposed -- if I had learned about Cross-Site Request Forgery for the first time today, and somebody asked me to brainstorm, what I would do, I would start off with a thought process that says, Well, what I really need to do is be able to differentiate between a legitimate user click or a transaction compared to something that looks like one.

So I think a good solution is to design the application that has the application assign a random server side token that is not present in the cookie and that the applications expects it back when an important transaction is submitted by way of get or post. It’s a good idea to make this, make sure this token is random, hard to guess, and that’s not contained the cookie.

If the application will then have to embed this parameter at a static variable in HTML as it renders its HTML so that it can be echoed back by its browser for every important get or post request. So what this will do is it’ll make it impossible for someone to write a malicious site that submits to a particular URL, your URL. Because in order for that submission, by way of get or post to be successful, the attacker will also have to guess this random token that changes every time a user logs in.

MR: Which is unlikely.

ND: Exactly.

MR: Yeah, never impossible but certainly unlikely.

ND: Yeah. Yeah, if I may. One of the other things from the impact perspective for the Cross-Site Request Forgery that I think is really interesting, I think it’s interesting from the perspective of demonstrating the building of the parameter. Cross-Site Request Forgery facilitates an inside out attack scenario that provides more evidence to the hypothesis that the DMC based network parameter controls strategy is no longer as effective or as valuable as it has been in the past.

So consider the scenario where you have an HR or payroll application vulnerable to Cross-Site Request Forgery in the company’s intranet, so it’s internal only. Now, an internal employee browses to a vulnerable site on the internet, right. This vulnerable site can now make the victim’s browser perform a transaction on the internal payroll site.

So what you have now is an inside out, out attack scenario where the victim initiated the attack process by browsing outbound to the internet. So the interesting point is your -- in addition to blurring of the parameter is that the Web browser itself is a trusted piece of software because it has access to both the intranet and internet.

MR: Yeah, I think the -- one of the most interesting things that you said in the dialogue to me was it gets back to application design. This is not an attack that you can necessarily stop with an application, firewall, or any other type of mechanism because, again, you think it’s a -- if you’re the Website owner, you think it’s a legitimate transaction.

You really have to design additional validations and verifications on important transactions because we can't necessarily make the assumption that the browser is that trusted piece of security software. Because again, I think we’ve shown through history that the browser exploits tends to be the path of least resistance for a lot of the attacks nowadays.

ND: Yeah. I think from a tactical perspective, from what do we do now. I think you’re exactly right. I agree with you that we have to educate developers to make sure they understand that they have to build this thing by design. But that’s one way of looking it and that is the immediate fix. And if somebody asks me what would they do for Cross-Site Request Forgery against the enterprise, I would say you got to let your developers know that -- and this should be a design principle -- It should be building to their DNA of how they write applications.

But one of the other things that I’m kind of thinking about and I’ve had some debates with other security professionals is that sometimes in our jobs as security professionals is not only to expect developers to keep but with attack vectors, but to give them platforms and tools that make it impossible for them to write an application that is susceptible to Cross-Site Request Forgery even on progress, right.

So if you look at what Java and Dot net did when, there’s they’re kind of -- Java and Dot net want a virtualized environment, right. And so today, if you want to write a buffer overflow, an application vulnerable to buffer overflow in Java.net, you can't, right, because by design, it won't allow you to do that unless, of course, you’re attacking the reimage cell, which I don’t think it’s a fair argument. But I think what I want to see from companies like Sun and Microsoft who develop these applications that are code upon. I would love to see them come up with new ways of developing lab research that if I’m a developer, I can't even write an application vulnerable to Cross-Site Request Forgery even if I wanted.

MR: You bet. And I think that’s critical and I think that’s a great way to kind of wrap the first session about Cross-Site Request Forgery. It’s obviously a new kind of attack. It’s a new way of thinking this whole inside out approach of really attacking the Web application via the browser and that was just tremendous information. So now let’s transition into the old free association part where everybody is a long time reader or listener of the Mike Rothman Security Report, we basically just go through. I’ll blurt something out and then Nitesh I’ll give you a sentence or two just to give me whatever comes off the top of your head. So let’s start with PCI 6.6.

ND: PCI -- my response to any sort of compliance regulation like that is...be secure and you’ll be compliant and it does not work the other way around. That’s what the first thing that pops up into my head when I think about PCI.

PCI. A lot of corporations look at security from a compliance perspective first. And so what they end up doing is spending more money than they should. So may take a look at one application. You look at it from the PCI lens, you look at it from the SOX lens. You look at from any other lens and they end up spending on parallel efforts on these problems. What you should be doing is approaching it from a pure security perspective and then doing a gap analysis to see how you can satisfy these requirements. I mean these requirements like PCI are not there to make you secure, it’s for the reasons that I probably don’t want to get into but its not to make you secure.

MR: Right. Exactly. And I think that’s a great point. I think it’s also a matter of 6.6, specifically, hits on a lot of the application security issues and there’s just been a lot of confusion about it. But again, if you look at the problem from the standpoint of making sure that you’re protecting your data, especially, credit card data, that the other stuff tends to fall into line. So one more. What do you think about Black Hat, the big conference? I know you’re speaking there next. So just, give me a couple of thoughts on Black Hat.

ND: I love Black Hat just mainly for the social networking opportunity I get over there. As far as the talks are concerned, I spend less time going to talks than I used to because everybody has blogs now and everybody’s so well connected. Usually, what ends up happening is you have a researcher that’s blogged about certain things and if you follow him, and go to see his speech, you’re not going to really find anything --

ND: -- you haven’t heard about before. So I mean it’s a good opportunity for me really to connect with people. I think that is so valuable and that makes Black Hat and any other conference like that totally worth it. And if -- there are a lot of people who go in there for the talks also but I would really, really recommend that they branch out and connect with people. I think that’s key.

MR: You bet. Because people like you and people like me. I’ll be at Black Hat next week as well. So looking forward to seeing you there Nitesh. Thanks again for ---

ND: You too.

MR: --sharing some of your time with us and as well as a lot of your expertise about Cross-Site Request Forgery. Is there someplace -- you guys in the IT Enablement Group with E&Y have some kind of Website where you can point people to, or just to find out how to get in touch with you, or if you got a blog that people can read, or follow what you’re up to. Just why don’t you let people know how they can get in touch with you.

ND: One of the things with the IT Enablement Practice that it is so cutting edge and its so brand new, we’re working on a site. I don't have a URL for that yet but we will have one really soon. I’ve actually seen some designs of it. I’m really happy. But until then, my personal site is at Dhanjani.com.

MR: Great. So check out Nitesh. Again, thanks again so much and thank everybody out there for listening to another edition of the Mike Rothman Security Report here on the ebizQ network. We will see you next month.

*** Editor's Note: Don't miss a single important development in security by getting ebizQ's weekly security newsletter delivered straight into your inbox. Just check Security Update and leave your email right here.

In this month's Mike Rothman Security Report podcast, Mike interviews Brian Chess of Fortify. Brian shares his wisdom about what's important relative to static code analysis, including some guidance on balancing scalability and precision. The flexibility of the rule set (especially to support legacy applications) is also a point of conversation, and then Brian really delves into the killer for most code analysis initiatives - ease-of-use. Overall, it's a good intro to what's important in Source Code Analysis.

During free association, Brian talks about PCI 6.6 and balancing code review with more active defenses like Web Application Firewalls. And speaking of fire, you'll get to hear a great analogy about how you can learn a lot about application security by taking a firehouse tour.

Listen to or download the 14:42 minute podcast below:

Download file

MR: Hello, this is Mike Rothman. Welcome back to the Mike Rothman Security Report hosted by my friends at the ebizQ Network. This month we have another great, great show, great guest and really an important topic. And this month we're going to talk about the idea of how do you select a Source Code Analysis project, program, solutions, setup tools, etc.

Because, again, I think that people are really finally on the development side starting to understand that there's a lot of leverage, there's a lot of benefit to eliminating security issues earlier in the development process and QA, certainly earlier than having to do a patch to deploy software, have to update websites and web applications. And to talk about this topic this month, I've enlisted a friend of mine named Brian Chess of Fortify Software. Brian, you there with me?

BC: Hi Mike, thanks for having me.

MR: Great. So Brian why don't you kind of start off and talk a little bit about Fortify and kind of what you do for a living and then we'll jump right into kind of some of the things that we need to watch for when we're looking for Source Code Analysis program or solution.

BC: Sure. Okay. So I'm one of the founders of Fortify. We got started about five years ago with the idea that we were going to help people try to build and maintain more secure software. And we're going to that with a set of products. Initially, a lot of security people are interested in tracking assessments and after they get a handle on -- oh, we got some security problems here, they get interested in remediation.

And, of course, the Holy Grail is just prevention, how can we help people stop introducing security problems into the code that they create. So at Fortify we do that with a set products. And the first one we're going to talk about today is Static Source Code Analysis.

Trying to look through code without running it and identify things that could be vulnerable or weak about the code. We also make software testing tools and tools that try and help people defend programs as they run. Okay. So we'll talk just a little about Static Source Code Analysis, in particular.

This is a topic that's near and dear to my heart because it's what I did my PhD on. And I did an engineering PhD and, of course, the real proof in engineering is well, can you actually build it and does it help people. So I think sort of, as Fortify is my real proof to the world that the academic that I worked actually does have practical merit.

MR: Well, and that's actually a great segue to kind of get into some of the challenges that an organization is going to have and face and when they start thinking about Source Code Analysis. And obviously, you guys been in this space for a number of different years.

When you sit down with a developer, when you sit down with a set developers and you say, listen, these are some of the gotcha's that you have to worry about when you start thinking about Static Code Analysis and kind of really looking into that source code. If you had to pick a handful of them, maybe two or three, what are the big gotcha's that these developers really have to worry about when embarking on this journey?

BC: Well, I'll try to pick a couple of things about the analysis capability itself that I think are probably the most important things to look for. And the first one I'll -- let me start off with maybe the most obvious and that is the algorithm that you use in order to go through the code and look for problems with it. And if you're any academic realm, this is it; this is 100% of the games.

You got to have some new algorithm that you can show people is the best effort. And usually that comes in at least two dimensions, scaleability and precision. So scaleability means the ability to look at a really humongous amount of code all at once and that's important, particularly, for security because security is all about context.

You can't really look at one line of code -- most of the time you can't look at one line of code and tell whether it's okay or not. You have to relate it to all of the code around it because the code around it might be what's protecting it. And of course, you got have precision too.

You can't just look at big bunch of code and say, oh, there's a problem in there. You better say precisely the problem is on this line and when there's an error interaction between these four things, then that's a security problem.

And so the outcome of good scalability and good precision is good prioritization of the problems with the code because not all problems are created equal. You know, there are little nit-picky things where you could do it a little bit better and that's good. You really ought to have an analysis capability that can point out all the little problems.

But what people want upfront is all the things where they could be had today. The kind of thing that somebody's going to be able to come in, find, and exploit easily. And so you got to prioritize on the look of issues that analysis algorithm produces in order to get that ranking right, that prioritization correct. I kind of lump that all under the academic side of things, the algorithms --

MR: Yep.

BC: -- that you might use. So that's item number one. I'll tell you the one that really takes just as much time and effort though is coming up with the rule set that drives the analysis capability. In other words, what are all the possible things that could wrong with the code? And so that defines not only the specifics of the vulnerabilities but how do other pieces of code interplay in order to define a vulnerability.

When I was in school, I could probably name have a dozen kinds of things that could go wrong with code, like buffer overflow. In other words, writing outside of array bounds that let someone take over a computer. And I possibly could've named that and maybe something like cross-site scripting where somebody can put their code on your webpage and essentially run any code they want in your user's browser.

I could've named a couple of those things but it turns out that the list gets really long when you start looking at more and more programing languages, when you start throwing in languages Java Script or PHP, or reach back to a language like COBOL. And so now you get actually literally hundreds of types of mistakes you could make and you got to write those all down in rule set to feed to your analysis algorithm to figure out what's essentially wrong with the code. And the rule set is just as important as algorithm.

MR: Yep. Now whose responsibility is it to build that rule set? Is it the kind of provider that you're looking for the tools? Is it the kind of developer that has to look and say, well, these are the things that are appropriate for my environment? Who bears the burden of that responsibility?

BC: Well, certainly the provider of these type analysis capacities should ship a good rule set that, for instance, finds things like buffer overflow or cross-site scripting because those are generic problems everybody has got. Now, the more interesting kinds of problems that you might encounter in your code could be specific to your particular program. And no providers are ever going to be able to give those to you because they don't know what your program is supposed to do.

MR: Right.

BC: So the ability to add rules to the system, to have programmers define their own rules, I think, is a pretty important one, often is an underutilized one. And it makes since that people when they first get started with Static Analysis they want to find the generic stuff.

As they get more mature, they can start adding rule sets on their own. I'll tell you what I've begun seeing lately, at least at Fortify, is people have started giving us rules. So for instance, CERT, wrote up a set of Fortify rules for their secure coding standards and then gave it to us so that we could distribute it to all of our users.

So this idea is that we're going to be sharing rule sets that accomplish different purposes; I think there is a lot of future there. So rule setting is item number two on my list.

MR: Okay. Good, number three?

BC: And when I was doing this stuff in academia, just did not even understand one iota of it and that is ease-of-use. And that's number three on my list for this reason. I guess this message is mostly geared to any security people in the audience and so here's my message to security people.

Programmers are never going to be security people. They've already got a job and they got a job writing code. We can't expect them to understand every kind of vulnerability out there up to the minute, completely have their knowledge of the security space; it just ain't going to happen.

And that means we always have to be transferring security expertise to non-experts. And if we don't that in an approachable fashion, then why would non-experts give us the time of day?

MR: You bet.

BC: So from a Static Analysis to the guy to do a good job of bridging that gap, bring expert security knowledge to non-experts. And it's a hard job for any kind of automation to go in there and look at your code and then to convince that there's a problem in code you just wrote because that's not something you want to hear -- as somebody who writes code.

MR: I think one of the key aspects of this whole progratic thing and those are great kind of tips in terms of what's going to help people understand what's important about Static Code Analysis. But it also bears at least a little bit of discussion around the whole program that's required to make this kind of initiative work because, again, you're going to be dealing with -- I won't call them hostile subjects.

But as you just said, Brian, at the end of the day most developers really don't want to know that they have security problems, it's not going to help them hit their delivery dates. And in most cases, the security folks may not have the political pull to actually keep a project behind or delay a project because of big security holes.

So again, a lot of this ease-of-use to me also gets into kind of making sure that the groundwork and the foundation has been laid so that this kind of change can actually take place in an organization, which is something that a lot of people don't really think about.

BC: So for the first year or two at Fortify, I really kind of grumbled a lot about the oh, those darn developers they don't care about security. And then somewhere in midstream I had this revelation that programmers actually think security is pretty cool, and it is. I mean it's really neat to think about how somebody might take advantage of a piece of software and contort it to do something it was never intended to do. And then there's, of course, there's the James Bond aspect --

MR: Right.

BC: -- getting into the secret files, or espionage, or thinking about how can you keep the bad guys out, that's all pretty cool stuff. The problem is that most people in software development process are told either subtly or not so subtly security ain't your problem, it ain't your job, go back, more features, I need them tomorrow. And at that point, first start thinking about, okay, well, how am I going to sweep all this other stuff under the rug?

Like, okay, well, if security ain't even suppose to be job, then if somebody tells me there's a security problem, I'm going to try and figure out I can weasel my way out of it. And so really, the problem with security usually start at top of the organization. It's very rare to encounter somebody who just will tell you explicitly, no, security that doesn't matter to me.

Usually, it's a little more subtle, like, oh yes, security that's really important but you can't have any extra time to work on it. It's just suppose to sort of come for free. That's the kind of a more subtle message that, hey, don't really pay attention to that stuff. And that's when you start having conflicts between the security folks and the people who are producing the functionality.

MR: Yep. So now let's kind of move into my favorite part of the show which is what I call free association. So I got two things I want to talk about today. I'll blurt them out. I know it's going to hard because we all certainly love the sound our own voices but if you can keep it to a couple of sentences. The first things that kind of come off the top of your head that'll be great. So let's start with PCI 6.6. Yeah, again, two or three sentence on 6.6.

BC: Oh boy, a horrible conflict. Its these two concepts that are really great which is you ought to look at your code, review your code. And this other concept that's really great which is you ought to actively protect your application like with something like an application firewall. But then they put this "or" in the middle. It shouldn't be an "or" it should be an "and". You should look at your code and build the right thing "and" you should actively protect it when it runs.

MR: You bet. That's perfect. That's exactly where I come down on the issue as well. And now that we're kind on the topic of web application firewalls, just give me another little bit on how kind of Static Code Analysis and really whole 360 approach that you guys take is really kind of complementary to what you should be doing with a web application firewall.

BC: Well, I mean we're right back on that same topic. If you think about how do you protect a building against fire? Well, you make sure that it's got emergency exits in it and that's something you design into the building, which also puts the sprinkler system in it. And that's an active defense against fire.

If there's a fire, the sprinklers go off and they try and put it out. And that's the exactly the same sort of thing that we're advocating with Fortify 360. In other words, take a look at the source code and try to wring the vulnerabilities out of the system, but also actively monitor that so you know who's attacking it, when they're attacking, how they're attacking. And that's how I see those two sides of the equation getting together.

MR: Yep. That's perfect. That's a great analogy. I hadn't heard that one before but, of course, I'll be happy to steal it as I do most of my great work. So with that, I want to thank Brian Chess from Fortify. Really appreciate you coming on the show today and writing some of your gospel as well sharing some of your wisdom about Static Code Analysis and the, obviously, on PCI and how to make the code review and the active defense or application firewall aspect of things works.

So thanks again, Brian. And with that, I will sign off another successful, at least in my own mind, version of the Mike Rothman Security Report here on ebizQ Network. Have a great month and we will be back next month with another show. Take care.

What? You've never heard of SQL injection? Maybe it's just an old friend for those of us who have been in the security business for a long time. In fact, SQL injection attacks have been around for at least seven years. However, they didn't gain widespread attention until about five years ago, when first-generation web applications (based on Windows Active Server Pages, Java, and early PHP) started to hit the mainstream.

SQL injection had been put on the back burner for a while, as cross-site scripting and other attacks got more media coverage. But now it's back -- and with a vengeance. This month, a new wave of attacks (originating in China) used SQL injection in a new totally automated fashion. The attackers used Google to identify web applications using SQL Server as the back-end. Then they built an automated SQL injection engine to compromise the web sites and insert malware into the database of vulnerable sites. These sites would then spread the malware to unsuspecting visitors, who become bots and zombies. The attack was sneaky and very effective.

What's most disconcerting is that hundreds of thousands of web sites were vulnerable to this attack and got nailed. That means there are a lot of first-generation web sites still out there not using the fairly simple defenses that can prevent SQL injection. Before I get the cart before the horse, let me define the attack and then talk about the risks.

SQL injection is a security vulnerability that targets the database layer of a web application. It allows the attacker to "inject" rogue SQL statements into a form and execute commands against the database. That's right -- the attack can drop tables or access pretty much anything that is in there, even private data. On the bad scale, having an attack with access to your entire database is usually pretty bad.

So what to do? Basically, SQL injection can be addressed in a number of fashions. The reason the attack fell out of favor for a while is because many of the new web application frameworks have built in defenses. So Windows .NET and J2EE take precautions to make sure SQL statements can't be injected into application form fields. If you are rewriting your applications in the near term, then the problem will pretty much work itself out.

Yet, I understand rewriting an existing application is not usually the path of least resistance. So now you need to figure out if you are vulnerable. The easiest way to do that is to get an application scanner and run it against your sites to find out your exposure. There are lots of offerings, ranging from free (wikto) to enterprise class (from IBM and HP) to services that check for all sorts of application problems (White Hat Security).

These scans will let you know which applications are vulnerable and then you can go about fixing them. Remediation can come in a variety of flavors as well. The first and best approach is to fix the application. Make sure to only use parameterized SQL commands to ensure that user input doesn't make its way into the SQL calls.

You can also front-end your database-driven applications with a web application firewall, which can block SQL injection attacks before they ever get to the application. These also range from the free (ModSecurity) to the enterprise class (Imperva, Breach Security, F5).

There are tens of millions of applications out there, most of which have been built without any concept or care for secure coding practices. The ramifications of this laissez-faire attitude are crushing, given the viral nature of attack propagation nowadays. The stakes are going up and we need to keep pace.

Amazingly enough, many of the secure application requirements in the PCI DSS standard are derived from having to defend against SQL injection. The two main aspects of Requirement 6 are (drum roll, please): code reviews and web application firewalls. So if you protect any kind of cardholder data, you'll become very familiar with this kind of database attack -- and also how to prevent it.

Some old friends you don't really want to see again, like my entire high school class. But I suspect you'll be hearing a lot more about SQL injection in the near term, so fix your stuff now, before you become tomorrow's headlines.

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.

Download file

In this month's edition of the Mike Rothman Security Report podcast, Mike interviews blogger extraordinaire Alan Shimel of StillSecure, as they talk about the pro's and con's of security vendor consolidation. This is a top of mind issue for application security professionals, since the acquisitions in the space (HP/SPI Dynamics, IBM/Watchfire) have already started.

Alan and Mike debate about whether it's better to buy from a big or small vendor and what to look for when making those choices. Alan is also subjected to the Free Association treatment, where we get to hear Alan's views on the IBM/ISS acquisition and how to deal with the really big security vendors, like Symantec, McAfee and Cisco. The transcript follows:

MR: Welcome back to the Mike Rothman Security Report here on the ebizQ Network. In this month's podcast, we're going to talk a little about vendor dynamics because, obviously, if you've been in the security space, or even in any technology space for a certain amount of time, you know that companies innovate then they kind of get integrated in terms of a consolidation into some of the bigger, whether it's IT applications, or security vendors, and then, obviously, their impact on customers as well as just how they're going to use that product, whether its continued to be invest in, whether its end of life.

So there are a lot of different types of discussions that need to go around this idea of vendor consolidation and you kind of maturation of a lot of the technology markets. And I think application security has already entered that phase so I think it makes sense to talk about it.

And today, I'm very pleased to bring on a very good friend of mine; Alan Shimel from StillSecure who has been in the technology space as well as the security space for many years has been through a number of these different cycles. And I'm certainly going to ask Alan to kind of illuminate a little bit in terms of what the best perspective from a customer viewpoint is in terms of how to deal with these consolidating markets. Alan, how are you buddy; are you there?

AS: Yes. Mike thanks very much for having me, always a pleasure to do anything with my buddy, Mike Rothman.

MR: So first of all, I mean I know a lot of people, especially since ebizQ Network tends to focus a lot on the application side that may not know who the myth, the legend Alan Shimel is so why don't you just give a couple of seconds on who you are and what your company does.

AS: Sure. So Mike, never under estimate the reach Alan Shimel first of all. I'm sure many of your listeners and readers are intimately familiar with me. But in any event, my name is Alan Shimel. I'm one of the co-founders of a company called StillSecure. And StillSecure is a secure infrastructure provider. We've been around about, geez, about seven or eight years now. And we have products in the intrusion detection prevention space, vulnerability management, and we're probably best known for our network access control product or NAC called "Safe Access".

We also have a secured networking platform called "Cobia", C-O-B-I-A, which is a free download. StillSecure is based in Colorado, Mike. Prior to StillSecure as you said, I do have a rather lengthy history in technology, IT, internet, and have as we like to say, it's not my first trip on the tuna boat.

MR: That's exactly right. So great. Lets kind of jump into the topic today, Alan. There are a lot of different deals in the application security space. So last year, HP bought SPI Dyanmics. You also have seen some consolidation in the source code analysis, Watchfire bought by IBM so a lot of the big application development companies and, obviously, big IT shops are starting to inflict their mass on this little world that is application security. And obviously, you've seen this movie before so, what are customers really have to worry about? What are some of the considerations that they should have if their vendor gets acquired?

AS: Sure. So a couple of things Mike. First of all, the three biggest lies in market consolidation, probably the biggest lie is, No, we're not for sale. Any of your vendors who are telling you that they're not for sale, are lying to you because everyone is for sale, Mike, you know that, I that. For the right price, any company be it public or private can be had. And too many times I've seen vendors answer customers by saying, Oh no, we're not for sale.

We're here for the long run. We want to do this. We want to do that. We're going to change the world. All fine and dandy but the fact of the matter is, Mike, company can be bought at any time. And I think the faster you realize that the faster you know. Secondly, I think from an end user dealing with their vendor perspective, Mike, it's very important to look at products that are standards based, right.

Because when you lock yourself into Black Box Technology, you are at the mercy of whoever buys, or whoever the acquiring company is, or even not in an acquisition. The company can close up shop tomorrow and you're left with a great flowerpot for a computer box. So buy stuff that's standards based where there is some sort of transition path. My two biggest pieces of advice.

MR: Yep. That's great. Application security is a little interesting in that there really isn't -- I mean there's obviously a lot of technologies that are standardized, right, the programming language the protocols, how you do things, even some of the attack vectors tend to be fairly standardized but I wouldn't say that there's like something like kind of TNC in the NAC world. So again, does that change your opinion about standards at?

AS: No. So look, whoever said TNC is standard that anyone uses? But that's a podcast for a different day. By standards, I mean what format is your data being kept in, your reporting, your results? Can you take that out? Can you export that data that is being accumulated into another database? Do you have open database schema? Are these reports, are they crystallized or can they be run in Crystal?

How is that data stored? Where is that data stored? Do you have access to that data? If its proprietary type of formatting or what have you, that's what I'm talking about. Yeah, everybody's going to have their own special source about how they examine code or what have you. But at some point, there's an end product they give you, Mike, and that end product needs to be able to be leverageable.

MR: Yep. Now, that's a great point. So if you kind of think about again, from the customer viewpoint, I can sit and talk to the small vendor. I can talk to, obviously, the acquired part of this big vendor. Were there any cases where kind of the warmth or the, hey, nobody ever gets fired for buying from IBM or HP. Is there ever a time when that kind of consideration really overweighs some of the functionality or business requirements why you would be looking at certain product?

AS: Yeah. Well Mike, there is a certain analyst down Atlanta way who has this big is the new small thing that would have us believe that no one ever does get fired for buying IBM, or HP, or Cisco. And maybe you are better off dealing with the big vendor only so you don't have to deal the evitable consolidation and change that seems to be the life of smaller vendors. But that road is fraught with its own dangers as well, right.

There have been many large vendors who would've bought a smaller vendor only to see the founding team of that or a brain drain. And it may wind up taking a very long time for that product to fall apart but it may in fact fall apart. And the big vendor may have to scramble to actually have it keep up with your needs and the reason why you bought the darn thing.

MR: Yep, yep. And the one thing that I would add to that, Alan, is being the originator of this biggest is the new small idea is as a customer, you can't forget about the business requirements ever, right. At the end of the day, we are all kind of working for whoever it is that we're working for but we are tasked with meeting the business requirements of that specific organization.

So once you kind of understand that, if again, one man's opinion is if you can find two companies with equal types of capabilities to meet your requirements in a similar way, I think there's certainly some comfort in buying from the big vendor. But again, not at the point of kind of sacrificing functionality that you absolutely need to meet your business requirements.

AS: Yes sir. And you got to make sure the big vendor's committed to continuing to provide that product. A lot of these guys buy it as a checkbox, right. And if it's a checkbox that you want, that's fine. But if you want more than a checkbox, make sure they're not just checkboxing it.

MR: You bet. You bet. And that's a great place to kind of segue into the next section of the Mike Rothman Security Report, which is, of course, free associations. So Alan, what I'll do now is kind of blurt out one or two, or maybe three, if I'm feeling all funky today, terms. Give me one or two sentences in terms of what you think of these things. So first place to start; let's talk about Internet Security Systems. And obviously, being acquired by IBM last year, what do you think of these guys?

AS: Well, look, ISS -- the ISS/IBM acquire wasn't the ISS of its heyday, but it was still a formable security team. I think, frankly, they're having a tough time finding their way within the monolithic IBM world, and they're becoming less and less relevant in the space if you ask me. I mean I can't tell you. We never run into them. The only thing happening, I mean, that's the danger of big is the new small, right. IBM has the checkbox. They've got to security but is it still relevant to what some of the pure play security guys are doing.

MR: Yep. And while we're on this topic, let's blurt out the next one, which would be big security or Symantec and McAfee. What do you think about big security nowadays?

AS: So you can't do big security without Cisco either. Let's not --

MR: Good point.

AS: For all the talk, they're still making the most money, I think, from security. They have the most security revenue so it's tough to compete. Look, I'm a smaller vendor competing with these guys every day. And you have a Symantec or McAfee that each control, I don't know, what is Mike, 20, 30 million desktops? And they have an entry in every silo of the market. You got to pick your spots on when you can go against them. They have inherent advantages at every step of the way. Thank God, they still don't all execute perfectly and they're enough people out there who are willing to give innovation a try with a smaller company.

MR: You bet. And that's great. I want to thank Alan Shimel, my friend. You can find him -- well, Alan, why don't you tell us where we can find you out on the web.

AS: Okay. On the web, you can find me. I was going say anything. On a Friday night or Saturday but -- on the web you can find me at StillSecureafteralltheseyears.com which is my own personal blog where I blog on security, and life, and technology, and kids, and everything else. And I'm now a member of the Forbes.com community of bloggers for business and finance.

MR: Wow.

AS: So -- yeah, it just it means I get to run some ads Mike. But anyway, yeah, you can hear me on that or look around at some security shows. You'll usually see me hanging out by the bar.

MR: You bet.

AS: The shorter little gray-haired guy next to me.

MR: Yeah. And I don't know who the short guy --

AS: I'm the taller gray-haired guy.

MR: I don't know who you're talking about. Again, thank you Alan for being here. Thank everybody for listening to Mike Rothman Security Report here on ebizQ Network. We'll be back next month with another action packed, quick-paced podcast to talk about some topic that's of import to us application security professionals. That's great. Have a great month.

Application security will be no different. Although still an early market, it's following the general deployment characteristics of its siblings in the network and host security environments.

One of the "big" research ideas I put forth in 2006 was a concept called "big is the new small." This idea reflected the reality that for most organizations, the idea of doing business with a security start-up created a risk profile they weren't comfortable with anymore. Certainly not for established and mature technology categories, like network security (firewalls, IPS, VPNs).

A manifestation of this mentality is the ongoing consolidation of security functions by the "aggregators," or "Big Security" as I call them, who bring market might and distribution leverage to accelerate the adoption of emerging security categories. Folks like Symantec and McAfee, and let's not forget the powers from other technology disciplines, like Cisco, Microsoft, HP, IBM and the like.

So what? Since you probably focus on applications and application-oriented security, why do you care? Basically, you've seen this movie before and it's happening again right before your eyes. Take a case in point last year, when within the space of a couple of months the leading application security scanning companies (Watchfire and SPI Dynamics) were acquired by IBM and HP, respectively.

As comforting as it is to have deep pocket parents like IBM and HP behind your favorite app scanner, is this a good thing? Will it remain a good thing? Should you start looking at other alternatives? Basically, you need an idea of whether consolidation is a good thing or a bad thing for you – the customer.

Unfortunately, history tells us that most deals are a lot worse for the customers than they are for the founders of the security start-ups, who tend to walk directly from the bank to the Ferrari dealership to flex their new found net worth. In a lot of cases, the acquired technology is buried within the larger company and innovation slows to a trickle, support drops off a cliff, and the technology dies a slow and horrible death.

On the other hand, is it any safer to go with a start-up that is still trying to figure out whether they can make payroll this quarter and if the investors are going to give them enough runway to grow their business? As you can see, there are risks on both sides. If you want a no-risk environment, go work…Ah, I'm actually not sure where you would work to eliminate risk. That's not an option anymore in any business.

Basically, you need to start thinking about #1 and that is you and the needs of your organization. That means focusing first on finding the product (or service) that most closely meets your needs, and don't worry about corporate heritage, funding, or ownership at this point. It's counter-productive. As discussed in my Buying Security Products guide, this first stage is about finding solutions that can meet your needs.

Once you have a "short list" of sufficient solutions, then you can start weighing the benefits and risks of working with a big company vs. a small company. Relative to application security, the entire business is not a stand-alone opportunity. There is a niche opportunity for maybe 1 or 2 of the firms to get to sufficient heft, but the reality is that application security tools need to be part of a bigger software development suite. So it's not a matter of if, but when the interesting, innovative tools will be swallowed up and integrated into a bigger suite of products.

That's what was so interesting about the HP/SPI and IBM/Watchfire deals. It wasn't the companies that did the deals, but where in those monstrous organizations the technology resides. Both of the acquired companies ended up in the application dev tools business units. Candidly, that's where the technology belongs.

So what's my conclusion? Basically, it's just a matter of time before all of the major players in application security are "consolidated" and subsumed into the collective of a big application development tools shop. Deals always create risk and angst, but it's no reason to not work with a vendor.

But it's also not a reason to do business either. Focus on what problems you need to solve. Find solutions and/or services to meet those needs. Then pick a vendor that you are comfortable with, regardless of how big they are.

While you are at it, build contingency plans – just in case. Application security folks should do that without even thinking anymore. Murphy's Law is alive and well. If it can go wrong, it will. So plan for that. If the vendor gets bought, make sure you have Plan B. If they are lost and stop innovating, let your wallet express your dissatisfaction. In the security business, deals happen. You should plan for that.

Listen to or download the 9:55 minute podcast below:

Download file

In this podcast Mike talks with Jeff Williams, CEO of Aspect Security, where they discuss everything you need to know about identifying and defending against the current scourge of cross-site scripting attacks.

MR: My friend Jeremiah Grossman over at WhiteHat Security actually has done a bunch of research that says upwards of 60 to 70 percent of websites are actually vulnerable to cross-site scripting attacks. So I'm very pleased this month to actually have lined up one of the preeminent experts on all sorts of different application security issues here too kind of explaining cross-site scripting, talk a little bit about how it is that developers can both address as well as make sure that their applications aren't vulnerable to cross-site scripting attacks. And with that, let me introduce Jeff Williams; he is Chief Executive Officer of Aspect Security. Jeff, how are you, buddy?

JW: Great. Hi, Mike.

MR: So hey, why don't you just kind of introduce yourself and Aspect Security for maybe a minute and just give people a feel for what you guys are about.

JW: Sure. I'm the CEO of Aspect. We're a small company. We provide application security risk management services. We also have some training courses and some services to help companies start writing better code across their whole STLC.

MR: Yeah.

JW: I'm also the chair of OWASP, which is the Open Web Application Security Project and which is a not-for-profit foundation focused on application security and I encourage everybody to go check it out.

MR: OWASP.com is exactly right. That was one of the things you were going to talk about a little bit later. So if you would, why don't we just kind of go over and give everybody kind of a pretty brief introduction to cross-site scripting and really why it is such a problem out there.

JW: Sure. So the underlying problem is really very simple; its developers are taking input from untrusted sources like the HTTP request and they're sticking it into their web pages without any kind of validation or encoding. And what attackers can do is they can send in little fragments of scripts to an application. The script gets echoed back into the HTML pages and runs in the victim's browsers.

So at the end of the day, it allows attackers to run scripts in the victim's browsers. And JavaScript is a full programming language. You can write very complicated applications in JavaScript that do things like steal data, and steal session cookies, and accounts, and all the stuff that you would put into a Web browser so that's why it's a serious problem.

MR: Yep. Do you buy this number from WhiteHat in terms of 60 to 70 percent? I mean when you kind of go into a new client's site and really start checking out what it is that they have, is this kind of the most prevalent issue that you find within their web applications?

JW: Well, it's definitely incredibly prevalent. I actually think the number is probably more like 90 percent. We almost never see an application that doesn't have some cross-site scripting problem in it; some of them are more obscure. Most of them are very easy to find, even a tool could find them. But they're not the most serious issue. I mean they're definitely important but in terms of impact, they're probably not the most serious.

I would put access control issues, authentication issues, in terms of impact as higher but there's no question that cross-site scripting is the most prevalent issue of application security.

MR: Yep, which actually brings up a good point. Obviously, there are things that are more serious. But what are some of the stuff? So you talked about JavaScript as being a full programming language, what are the things that attackers could do if they were actually able to perpetrate a cross-site scripting attack and actually gain control of the user's browser?

JW: Now, when you authenticate with a Web application, you type in your username and password, and the site issues you a session cookie; it's like a temporary hand stamp that you might use to get in. And if the attacker steals it, they can become you, it's just as good as stealing your username and password. And JavaScript has access to the session cookie.

So if an attacker can perform a cross-site scripting attack, they steal the session cookie, and then they just become you. They can do anything that you can. Now, another thing they can do that's with cross-site scripting that's even more serious is they can inject what's called an "XSS proxy" into your browser, which accesses applications as you.

So the attacker is actually using your browser as a proxy to browse the Internet as you; so sending out requests through your browser and then go to sites that trust you. So they're using you as that trusted man in the middle and using your credentials to access sites and you might be totally unaware that any of this is happening.

MR: Yep, which could clearly be our problem. So obviously, it's something that might not be the most serious but it's certainly something that we want to address because it puts our users at risk, or our customers, if you're in some kind of e-commerce type of application. So if you had to say that there were one or two or maybe three things that developers can do to kind of avoid this issue, what would they be?

JW: Well, I mentioned at the beginning, the underlying flaw is that they've failed to validate their input and do the appropriate output encoding before they put that input into a webpage. So there's a bunch of different approaches to that, but really anytime you get anything out of the HTDP request, like a get parameter, or get header, or get a cookie. Anytime you get stuff out of the HTDP request you autovalidate it, and I'm talking about white list validation; not just checking for a view bad characters because that's not going to get it done. You need to check if it's a zip code you're expecting it should look like a zip code.

So put a regular expression there or compare it against a list of known good values, something like that. And then for output encoding, anytime you deal with an interpreter, you want to do the appropriate output encoding. And for HTML that means you want to use something like called "HTML Entity Encoding", that's when you replace like the less than symbol with "<" and a bunch of different characters like that.

You should encode everything that you're not really sure is safe for the browser, that's all the special characters, anything that isn't alphanumeric you should probably HTML entity encode before it goes into the browser. Don't do a black list encoding where you're just encoding three or four characters; we see that an awful lot and it's dangerous because attackers know how to bypass those things.

MR: Yep. Yep. And so it's really one of these things where it continues to be a kind of a arms races where you can do the output encoding and that certainly helps, but really the white listing approach is kind of interesting to me because, again, what you're trying to do is only specify what can be allowed on your site and within the application as opposed to kind of looking for known types of attack vectors. It just seems to me like a much more leverageable and strategic way they go about building your application.

JW: That's exactly right. The black list approach means you're going to constantly have to maintain the black list and add new characters as attackers develop new techniques. The white list approach, if you say it's a zip code, and its only five digits or five-four, it's like that forever. You're never going to have to change that definition so it's actually much more efficient long-term to just do the work and do a positive security model for your validation.

MR: That's exactly right. So Jeff , I want to thank you for kind of the little primer on cross-site scripting that was certainly valuable to me and I know the rest of the listeners here at ebizQ's network. So what we always kind of end up at the Mike Rothman Security Report with a little session I call "Free Association".

So what I'll do is I'll blurt out a statement or two and I just want a real quick top of mine one sentence or less type of approach from that standpoint or answer. And again, we're just kind to try to have a little bit of fun with this but; again, I do think that it is pretty instructive to understand kind of some of the top of mind issues are. So you game for that?

JW: Sure, let her rip.

MR: Okay. Great. First thing I'll ask you about are application scanners.

JW: Pretty good at finding cross-site scripting flaws, not great at finding a lot more, but probably should be part of your balanced breakfast.

MR: Great. What about the SDLC?

JW: If you want to do application security right, you got to get in your SDLC. I strongly recommend getting organized and maybe thinking about building the process around an enterprise security API. I just started a new project that OWASP about that. You can find it at OWASP and the project name is ESAPI.

MR: And that's great. Let's just kind of wrap up a little bit with OWASP. So in one sentence, again, why should folks get involved?

JW: It's a huge free and open community dedicated to application security. we've got a zillion documents, a bunch book links, PDFs that you can download for free, and a ton of great tools, some of the leading application security tools including WebScarab, which is a testing tool, and WebGoat, which is a full application that you can use to learn how to test application security.

MR: That's perfect. I want to thank Jeff Williams from Aspect Security; that is aspectsecurity.com. Is that right, Jeff?

JW: That's right.

MR: If folks want to go find you. Go check them out. Again, one of the preeminent experts on kind of Web application security out there. And again, this is Mike Rothman. Appreciate everybody listening in to the Mike Rothman Security Report and we will see you next month.

This month I want to dig a bit deeper into the cross-site scripting (XSS) attack. The type of issue is rather pervasive out there in the wild, and most web site developers have no idea what an XSS is and how to fix it - until their users are getting hurt. The sad truth is that many web sites do''t pay as much attention to XSS attacks because they aren't used to compromise the web site's data.

These attacks are used to steal information from the browser of the user, making them perform unauthorized scripts because they believe the website they are visiting is trusted. It's a nasty attack and relatively easy to detect, though harder to stop. Let's jump in.

What is XSS? How does it work?

A cross-site scripting attack uses an unsuspecting web site to launch an attack against a visitor, leveraging the "trusted" nature of the underlying web site. When the visitor's browser renders the compromised page, the malicious script, which is stored on another site (ergo CROSS-SITE), is executed providing access to information resident in the browser of the visitor.

XSS comes in two flavors. The first, called a "stored" attack, involves the offending script command to be entered into a text block. This could be a comment field, search box or message forum, etc. This can be a problem for any of the "Web 2.0" types of applications that allow user comment and feedback. If it allows visitors to insert and store data in your application, then it's vulnerable to a stored XSS attack.

The other type, "reflected XSS" involves more traditional social engineering. The visitor needs to click on a link, which has the malicious script embedded. The web site then "reflects" the script back to the visitor and it's executed in the visitor's browser.

What is the impact of a successful XSS attack? Who gets hurt?

Basically, the user gets hurt, not necessarily the web site, and that's been the big sticking point in taking XSS attacks seriously. The first generation of XSS attacks really focused on nuisances like cookie stealing, but more recently a new type of very malicious XSS is appearing. These new attacks can bring down web sites, cause users to take actions like they don't want to (like the Samy MySpace worm), and even host a phishing site within a real site.

To illuminate a bit on this last example, imagine that you are buying something on yourfavoritestore.com. So you go to their web site and everything checks out. The SSL certificate is right and the domain is right. You're good, right? Wrong. What happens if you enter in your userID and password and it turns out a malicious script in a comment field on that page launches a script that takes the data from your form and sends it to Eastern Europe? You'll never even know what hit you.

It's like an ATM attack where the bad guys bolt a fake front on an ATM machine. The fake front reads your card and then passes it to the real ATM machine. You get you money, like you expect - but the bad guys have your number and your PIN. XSS can do that, but a lot more transparently and with a lot less risk to the attackers. No wonder this attack is very prevalent.

Detecting the XSS

So how to you detect a potential XSS problem? Technically it's not that hard, although the scale of the problem is significant. Basically you have to check every form and field in all of your web sites. Anywhere someone can enter text into your web site needs to be checked. Obviously that's a tall order for a human, so you are best off looking at scanners to help automate the process.

How to fix the XSS?

Fixing the XSS is also readily doable. Here are three options to consider:

1. Web application firewall - Yes, a WAF will help to block if your web site calls out to a foreign site to execute a script. So if you front end your application with a firewall, you can largely eliminate the problem. Of course, all your traffic needs to go through that firewall so make sure there aren't alternate routes into the application that could get around the defense.

2. Code frameworks - A number of the packaged application frameworks are down with XSS, and have built-in validation processes to make sure that forms and fields cannot accept foreign scripts. Microsoft (once again) is leading the business on this issue, with ASP.net offering many of these advanced validation checks built-in. J2EE and Rails offer a lot of tips and documentation to defend against XSS attacks as well.

3. Developer training - It's great that a lot of the frameworks add defenses to stop XSS, but ultimately you want your developers to be aware of the attack vector and to code their applications with these issues in mind. Of course, we are a ways off from developers caring about security, but through consistent evangelizing and persistent testing of applications, you can get the developers on board.

XSS is a scourge, but a manageable issue. With a little preventative scanning and some proactive mitigations, much of the risk of XSS can be eliminated from your web sites.

Listen to or download the 11:52 minute podcast below:

Download file

This month Mike chats with Kevin Beaver of Principle Logic about the ins and outs of application testing. They discuss how network and system penetration testing differs from testing applications and why it's critical to look at the problem from both sides. Kevin also provides a little view into his tool bag and discusses what tools he uses for what jobs and, finally, Mike subjects Kevin to the free association treatment. Hear what Kevin has to say about Metasploit, source code analysis and cross-site scripting.

The transcript follows:

MR: Hello, this is Mike Rothman. Welcome back to the Mike Rothman Security Report on the ebizQ Network. This week we are going to tackle the concept of application testing. And you know whether we want to call application scanning, or you want to call it application penetration testing, you know, there are a lot of different ways to talk about the issue.

But given the fact that applications are still a bulk of and becoming increasingly the majority of where many of the attackers are going first, putting your applications through its paces, really understanding, you know, that the issues are, vulnerabilities, exploitabilities of that application are is absolutely critical. And I'm very pleased to have a local Atlanta guy, a good friend, Mr. Kevin Beaver with me today. He is with a shop called Principle Logic. Kevin how are you?

KB: Mighty fine. Doing great Mike, thanks for having me today.

MR: Oh, that's great. That's great. So Kevin why don't give everybody a little bit of background Principle Logic and on what to do because you're very well known in the networking and systems security areas but maybe not so much on the applications side.

KB: Well, I'm working on that. I am an independent information security consultant. In my practice I basically focus on performing security assessments, pointing out the flaws in networks, applications, databases, and even security operations so really end-to-end services. And I've also been doing quite a bit of expert witness work lately, and I do a lot speaking, and I have this new audio program series called "Security On Wheels".

MR: Well, that's great. That's great. So since a lot of what you're doing is, you know, kind of assessments and really helping folks go through and understand, you know, what's actually happening in their infrastructure as well as their applications. You know why don't we kind of start with a little bit in terms of, you know, how you tackle a network assessment, or a systems assessment and how that's different than, you know, how you tackle an application assessment, you know. Well, is it is that the tools, is it just the methodology, or the mentality, or is there no difference at all; a test is a test is a test?

KB: Well actually, by and large a test is a test is a test. I think the big differentiator is the tools that use. You know whether you're looking at a operating systems, network infrastructure devices, or web applications, the methodology is the same. I've used what's called the "Ethical Hacking Methodology" where, you know, you get in, you plan things out, you do your testing, which involves, you know, performing your initial scanning, your reconnaissance, your actual vulnerability findings, and then any exploitation, and then once you're done with the testing, of course, you got to go in and analyze your results, you got document your results, and then deliver the reporting phase essentially.

So really regardless of what it is, if it's an IP address, if it's a URL, if -- basically, if it has an on/off switch, it's essentially the same. I think the biggest differentiator is the tools. And whenever you're looking at an entire network of systems -- of operating systems, routers, firewalls, switches, you name it, you're going to want to use good tools that are specific to those type of devices. I mean for instance, I use QualysGuard to find network and OS level of vulnerabilities and then follow-up with tools like Cain and Metaspoit, and some of the Back Track Live CD tool's to exploit the flaws.

MR: Yep.

KB: A lot of times, if I'm doing an internal network assessment, I'll use a network analyzer called "OmniPeek" and I'm able to quite often find some network anomalies that you'd never find otherwise, you know. And he thing is with the network layer or network-centric vulnerability assessment tools, they're going to look at everything, they're going to look all the way up to Layer 7, you know, look at the Web server and maybe some of the web application components, but they're not going to dive in deep enough and that's where these applications, security specific tools come in to play.

MR: Good. So that's actually a great segue into some of these tools. Obviously, there are scanners. Obviously, there are, you know, some tools that are being positioned more as penetration testing tools so -- you know, again, you've been contracted to give SecurityInsight.com, for example, and by the way don't do this.

KB: I won't; I don't have permission.

MR: Yes, that's right. So let's say, you know, I contract you to kind of figure out where the holes are in my application or my shopping cart or something like that. You know, how do you get started? What are the first couple of things that you end up doing?

KB: First couple things are determining what's the URL, obviously. And then figuring out do you want to look at this from a true outsider's perspective or do you want to look it both from an outsider's perspective as well as a trusted user's perspective. And a lot of people they just look at their Web apps from the outside.

They assume, well, you know, we've got these Eastern European bloc countries, and Asia, and all that stuff, they're trying to hack into our system, that's what we need to worry about the most. But a lot of people overlook the fact that somebody on the inside, somebody that has a trusted access into the environment may actually be able to get in and manipulate the URL, get in a poke around and do things with the application that allow them to penetrate the system.

MR: Yeah. So, either you'll go in, you'll kind of check out the URLs, you'll kind of look at it again depending on whether you're kind of acting as either an outsider or a potentially trusted insider. You know there are certain, you know, set of tools or a number of tools that you have in your little kitbag that help you do this stuff?

KB: Absolutely. Even if I'm running a general application assessment, I tend to use some of the network level tools like QualysGuard and Nessus and things like that just to get an overall picture of the server that the applications running on and maybe find stuff that some of the higher level scanners aren't going to fine. But then I'll actually start digging in and using tools like HP's WebInspect is usually the primary tool that I use.

MR: Yep. I mean have you seen any difference in level of support or, you know, kind of responsiveness since they were actually bought -- since SpyDynamics, is again, another local Atlanta company was acquired by HP?

KB: No, I mean if anything, it's gotten better so. I've always had a good experience with these guys and that's why in my work I strive to be vendor neutral but if I find a product and a vendor that I really like and really believe in, I'm not ashamed to tell people who it is and to point people in that direction.

And, you know, just like QualysGuard, I think that WebInspect is an excellent tool if you're looking to find the most vulnerabilities without all the false positives and all the noise that a lot of the other ones will generate.

MR: Yep, I'm sure a lot of listeners certainly appreciate that perspective because --

KB: Sure.

MR: -- and again, there are just a lot of solutions out there and to hear from, obviously, somebody knowledgeable in terms of what works -- that's, obviously, you know very helpful. So, you know, let's talk a little bit. So you've got some tools but the tools will only get you so far, how much of doing these assessments, you know, well get back to your own skill or your ability to interpret the information that comes out of the tool versus the tool itself?

KB: It's almost always about 50/50. It's 50 percent tools and 50 percent human expertise and context. You know a lot of people they go and they run their scans but they never do any in-depth checking or validation of the findings of their tools. And you've got to take your security scanner results with a grain of salt. And the thing is no matter how good the tools are there's simply not going to find us certain vulnerabilities.

And really, likewise, no matter how good you are at finding security weaknesses, there's no way to test that the level that these security testing tools can test. So it's got a be a good trade off, it's got to be good balance and, you know, using good tools and pulling in your expertise, your experience, your analytical abilities is really important to find out what matters in the environment that you're testing.

MR: Yeah. Great. So, you know, anybody that's listening out there don't worry you will still have a job tomorrow.

KB: Oh absolutely.

MR: We're not having a Terminator action here where SkyNet is going to come out of the sky and -- and make all of us security folks irrelevant.

KB: Well, as much as the vendors want you to believe that all you need is their tool, it's simply not the case.

MR: Well, that's great. That's exactly what I think everybody wants to hear. So now we'll kind of bridge into what I call "the free association" part of the -- of the show. And, you know, the rules are pretty simple, Kevin. I'll blurt out a statement; you kind of provide your perspective and what I hope to be a sentence or less.

KB: Okay.

MR: We'll do a couple of them and, you know, again, we'll just see where it goes. So let's start with Metaspoit.

KB: A must have security testing tool. That's the first thing that comes to mind.

MR: Yep. No, that's great and that's what exactly what free association is about. And for those of you that aren't familiar with Metaspoit, it's actually an Open Source exploit penetration testing service or package, I guess, is what you would call it. But it actually uses real exploits to help compromise machines and understands, you know, where the real holes are as opposed to broader vulnerabilities.

KB: Yeah, it actually helps you to show just what can happen out when QualysGuard and Nessus, and all these other tools find the missing patches. It allows you to take things to the next level.

MR: You bet. Source code analysis?

KB: Got to have it, not seeing enough of it.

MR: And Cross-site scripting?

KB: Still see it everywhere; don't know why it's not fixed yet.

MR: That's exactly what free association is all about. Because you know again, I mean, I'm seeing a lot of the same stuff which is, you know, source code analysis is just hard and, you know, this is part of the reason I'm excited to continue to work withebizQ is that it's largely an application developer that their heritage is certainly application developers and SOA, and a lot of application oriented stuff. And, you know, it really is an evangelizing role that we security professionals have to take with, you know, kind of the idea of building security, and building secure applications sooner rather than later. And the fact that a lot of people are, you know, not embracing source code analysis, and a lot of people, you know, still are plagued by, you know, again, pretty straightforward, you know, attacks that can be solved with things like, you know, input validation, you know, like SQL Injection and some of these other buffer overflow issues. I mean, you know, again, you look at from a security guy standpoint, you know, like why is this stuff still happening? But again, it just gets back to the evangelizing that we as security people continue to have to do.

KB: Right. And you know what's happening? The essence of all this is that developers by and large, I'm not saying all of them, but by and large, from what I'm seeing, they think that as long as they're checking for memory leaks, checking making sure they have strong password requirements, and they're using SSL, then that's what security is all about, but we know that it's way more than that.

MR: You beg; we do know. So with that, Kevin Beaver, thanks so much. Why don't you again, give us some URLs so the listeners know where they can find you.

KB: Absolutely. My business is at PrincipleLogic.com. I have links to all of my articles, Webcasts, podcasts, you name in my audio programs both free and for sale are at SecurityOnWheels.com.

MR: SecurityOnWheels.com. Thank -- thanks again, Kevin. Thanks everybody for listening to the latest edition of the Mike Rothman Security Report on ebizQ Network and we will see you next time.

Wouldn’t it be nice to know what the bad guys are going to find before they find it? No, I’m not going to tell you to buy a crystal ball, though that may not hurt. A concept I’ve been pushing called "security assurance" focuses on testing your environment, including your networks, systems, as well as applications. You use the same (or similar) tools as the bad guys do, and you try to break your stuff.

I believe every company of size needs to have a dedicated team focusing on trying to compromise business systems. Sure it’s an investment, but it also provides significant peace of mind -- and we all know that is priceless. To know what will happen when the bad guys exercise your defenses gives you a huge advantage in the ongoing battle with the dark forces that are trying to steal your customer's private data and your intellectual property.

But testing your application after it's been let loose on the world is not too helpful. So one of the first jobs you have to tackle is evangelizing the need to get the security team involved early and often in new application initiatives. I speak to lots of folks where the security team doesn't find out about new applications being deployed until servers and infrastructure is being installed to support it. Suffice it to say, that's just too late to have an impact.

Once you figure out which applications are happening and when they are going live, then you need to approach the development lead and work out a testing scheme that allows you to put the application through a security gauntlet before your customers (and the bad guys) do.

The main tool in your arsenal is going to be the application scanner. These tools mimic a number of attack vectors, like SQL Injection, buffer overflows, and cross-site scripting, in order to find the break points in your application(s). If you aren't doing proper input validation, the tool is going to find that. If you can bring down the application via a buffer overflow, you'll know.

Network and system-oriented scanners have been around for years and the technology is very mature. Historically, scanners focus on identifying the vulnerabilities in a non-intrusive way. Penetration testing products on the other hand (Metasploit, Core IMPACT, Canvas) use actual exploit code to see which systems can be exploited. Pen testing tools brake stuff by design, and I assure you -- that is a good thing.

But the line between vulnerability and exploit is not as clear in the application world. It turns out the only way to figure out if an application is vulnerable is to actually launch an attack. So there is definitely a blurring between application scanners and pen testing tools. Let's be clear -- to a customer, the difference is meaningless. You want to know if a bad guy can own your application. You aren't interested in semantics and vendor category definitions.

So what's an application scanner good for? At this point, they are pretty effective in determining the simple (and well-known) attacks, like SQL Injection and cross-site scripting (XSS). More complicated attacks, using holes in JavaScript and things like cross-site request forgery (CSRF), are more problematic to detect. The point is atool provides a good start to finding the obvious application holes that a bad guy could drive a truck through.

I do need to caution you that tools will only take you so far. Don't get too comfortable that a skilled attacker won't break your application via an advanced attack or logic error.

Which brings up the main point: You still need good, competent, skilled personnel to test your applications. They can uncover how your business logic might allow a hacker to exploit how your application handles sessions or recovers passwords. These tend to be the low hanging fruit for the bad guys.

Skilled application testers are worth their weight in gold. Seriously! By taking a very critical look at your application before it goes live, you will save yourself a ton of heartburn and maybe even protect your customer's data while you are at it. Is that worth a little hassle during the development cycle? I think it is, but I'm not the one telling the sales people that the application isn't ready because a hacker could make mincemeat out of it.

So, even with a commitment to testing using tools and skilled people, you still aren't done yet. You also need to be able to create a sufficient level of urgency to fix the issues you find and maybe even delay an application from deployment. But that's another topic for another day.

There are a lot of levels in security that need to get "stitched in" to provide process level security in the SOA enterprise. A quick review of the more obvious ones:

1. Identity verification ... authenticating the user is who they claim to be (password, digital signature, ...)
2. Role assignment ... defining a set of corporate "roles" across the whole enterprise, and provisioning users to them.
3. Access enforcement ... via SAML assertions(?) around key service point access to ensure only authorized users with the correct ID can invoke selected functionality.
4. Monitoring / reporting all access to sensitive (ex: customer) data ... a BAM function.
5. A set of business process definitions (BPELs) which correctly link the authentication and BAM services into the existing processes flow to meet predefined security constraints in SOA service governance policies.
and so on.

Question: How does an architect step back and compose "SOA Security" out of these discrete components, supplied by a variety of software vendors? Are there SOA best practices, SOA security design patterns, precanned BPEL or ... ??

Answer: There is no easy answer to that question without going into an entire treatise on SOA Security. But this topic, and many others, will be covered extensively at next Wednesday's SOA security roundtable. Sign up right here.