Why do Web servers represent such a compelling target for hackers?
It's been interesting [to see] how the bad guys are changing their tactics over time. Traditional network security has gotten better. If you go back a decade where bad guys were attacking different protocols and ports that were available from the Internet. Thankfully, now it's pretty much standard for every organization to have a network-based firewall. So a lot of those doors were being closed off. Now a days the door that is almost always left open is the Web. Pretty much every organization let's [traffic] through port 80 and port 443. The bad guys and the penetration testers … know that those ports are always open.
Is it really just about the firewall? Should the firewall and SSL be the only means of protection?
No. A network firewall helps to block some of the other ports if you are running some other services and you don't want people getting to them. SSL does of course have a place. It helps really to do encryption and that's the main reason people use it. The only thing that it helps protect against is if I'm going to send my credit card information to Amazon or another website, I'm going to send it via SSL because if there is somebody in between that computer and that website and they're sniffing traffic, I don't want them to see my information so they can steal it. But SSL is not adequate for protecting against today's Web attacks because what happens if I'm the attacker. I can go through an SSL tunnel. SSL is not going to stop me from going through your website. If you're going to protect your Web servers and look for these types of attacks you have to be able to look inside encrypted traffic. That's another reason why Web app firewalls are becoming more popular because that's another feature they can provide.
Listen to the interview:
Virtual patching, Web application security: Web application security expert Ryan Barnett explains why Web servers represent such a fertile ground for hackers, whether developers will begin to create more secure code and the benefits of a technique called virtual patching, which tricks hackers into thinking a Web application has been patched. Barnett is director of security at Breach Security.
We seem to be seeing more reports of groups getting together to try to get developers to think about security. Do you think it is working?
I see some evidence that there's starting to be some momentum. I would agree that more developers need to be trained in secure coding. A lot of the bugs that we see in the field that are being exploited are injection types of flaws. It's general input validation that is lacking when you're taking some input from a client and you don't do any kind of balance checking to make sure it's the right size, format and character sets. If you're not doing that, that's why things like SQL injection attacks work. Those types of things are not being taught. Getting universities to change their curriculum is not very easy. The number one problem that I've seen in businesses, organizations and development is the lack of contractual language specifically [addressing security requirements]. What's missing is not only functional requirements, but also security requirements. How do you handle errors? Do you fail securely? How are you doing authentication? Those need to be spelled out. Also when you are giving deliverables to your customer, if it's not up to snuff from a security perspective, the paying customer doesn't have to pay money to fix it.
You are affiliated with the Web Application Consortium and you are doing some threat classification work for them. Tell us about that.
We're working on version two right now. One compare and contrast is the open Web Application Security Project (OWASP). We're kind of sister organizations with the same goals. We want to educate the community on Web application security problems and we offer different papers and research. OWASP has a top ten list of vulnerabilities. It's very useful and it's gotten a lot of publicity mainly because a top ten is much more consumable. With our threat classification, we wanted to expand upon that. What we're finding is that so many people were gravitating to the top ten list that they would focus on those but they need to realize there are other vulnerabilities out there. So we're expanding out and trying to list a bunch of the vulnerabilities and the attacks that can exploit those. We break it down to some different areas: authorization, authentication issues, injection flaws, error messages, and logic issues as well, but mainly we're also updating in the next version to include XML vulnerabilities because those are becoming more prevalent with the technology that's out there. Two years ago you told Stephen Northcutt in an interview that virtual patching is going to become more popular because it speeds the mitigation of Web application vulnerabilities. Do you still feel that way?
Yes. When you identify a Web application defect or flaw, how quickly can you fix it? The idea of virtual patching is to say you have some sort of a toolset, device or appliance, external to the Web application, where you can go in and essentially create a rule set or policy that describes the vulnerability or the attack. If somebody remotely tries to exploit that vulnerability the policy will stop it. Nine times out of 10 writing a virtual patch is done on a Web application firewall. That's mainly because a Web application firewall is going to have enough flexibility and accuracy to describe that vulnerability and when somebody's trying to exploit it. From an external hacker's perspective, that vulnerability is virtually patched. They try and exploit it and it doesn't work. They have no idea if it was patched in the code for real. The point is they cannot exploit it. Virtual patches shrink the time-to-patch window.