Drawing A Line On Web Application Security

Web application security is of particular importance because so much of our digital life is spent interacting with Web applications. Lori MacVittie, technical marketing manager with F5 and former Network Computing senior technology editor, has spent years kicking the question of where application security belongs -- in the network or the application -- back and forth. But I want to draw a line in the sand: Don't depend on Web application firewalls to fix your software problems.Don't let Lori's title fool you. She spent years in enterprise application development before coming to Network Computing and years evaluating development and network products heading up the magazine's application infrastructure coverage. She gets it. Her blog should be on your must-read list if you deal with application infrastructure. Her commentary is pretty vendor-neutral.

Anyway, I kicked up the discussion again on Twitter and Lori suggested "4 Reasons We Must Redefine Web Application Security." Her basic point is that the term Web application security can cover everything from IP networking up to input processing. I don't disagree with her. Practically speaking, it doesn't matter if your application is compromised because of a vulnerability in TCP, SOAP, or the application code. What does matter is whether an attacker can subvert your Web application and do things you never intended.

Our ongoing argument, which we have jokingly agreed is akin to the battle between Lazarus v. Lazarus on Star Trek's "The Alternative Factor," boils down to me thinking application security belongs in the application and Lori thinking application security in the network is OK. Yes, we both agree that there are functions for both the network and the application to play in application security.

Functions like SSL off-load, user authentication, protocol and format conformance validation, and denial of service mitigation can be effectively handled by network devices because the protocols, formats, and behaviors are fairly well defined, simple, and don't change much. Using dedicated hardware to improve encryption performance is a no-brainer and you definitely want to tie your authentication system together where it makes sense to do so. Protocol validation also is pretty straightforward. If you see SSH traffic on port 80, which is usually used for HTTP, that will in all likelihood indicate someone trying to hide and you probably what to shut it down. Even some of the service basDoS attacks Lori mentions, like leaving open numerous HTTP sessions as well as data format denial of service attacks like nested compressed archives or XML files, can be handled by the network because they are well-understood. DoS attacks generally leverage weaknesses in the protocol specification, typical deployment practices, or a specific implementation and DoS attacks generally don't lead to information disclosure. I don't want to diminish the impact of a DoS attack, but I'd prioritize information disclosure over DoS most of the time. Information Disclosure

Vulnerabilities in Web application logic, the code that is executed as part of the Web server environment, often lead to information disclosure and need to be handled in the application logic by fixing the problem where it occurs. There are limits to what we can expect from a developer, a point alluded to by Lori. I wouldn't expect a Web developer to be responsible for ensuring that the Web server is properly handing sessions or for the developer to investigate TCP stack problems. I do expect Web application developers to be able to handle logic and code security vulnerabilities in the logic and code they write, however. Pushing that responsibility off to a Web application firewall, or anything in the network, seems like a poor choice because data should be handled in context and the context is within the application. An application should be able to handle failure on its own.

Web application firewalls may have their place and they may be effective at thwarting Web application attacks, but let's face it, a Web application firewall is one more thing to purchase, deploy, manage, and configure. You need to add WAF modifications to your application change control process and, in some sense, you have to recreate some of the same application logic in the WAF as you do in the application. Seems like a lot of work for something that can fail to protect your applications anyway.

Then there is the very real problem of application security becoming someone else's problem. A Web application firewall vendor told me several years ago (I forget who said it or the vendor. Great memory, huh?) that some of their biggest customers are independent software developers (ISVs) who ship the WAF as part of the application delivery. I asked him why and he said ISV's want their developers focusing on features like rich Internet applications described by Roger Smith in "Setting Priorities for Next-Generation Web Apps" [registration required] and robustness and not security. Really? Really?

That's just irresponsible. Would you want a steel worker overlooking a concrete problem because it wasn't their area? Would you want a waiter overlooking a cook sneezing in your dinner because you aren't in the waiter's section? Of course not. You want those people to point out problems before they can cause harm. Wouldn't you expect the same from application developers? Who better to use secure coding methods than the coders themselves? If I look at the Top 10 application problems listed by WhiteHat Securities December 2008 WhiteHat Website Security Statistics Report, I know nine of the problems can be solved in application logic. I am unsure about HTTP response splitting and will have to look into it.

Understandably, using secure coding methods doesn't mean that your application will be secure. Applications are complex. People can still make mistakes. New attack vectors can develop. Developers could end up using a library that has a vulnerability unknown to them, like what happened with the widely use zlib compression library bug in 2002, or a vulnerability could be opened in an related but indirectly used system, like the weak key generation problem found in Debian's OpenSSL package. But that doesn't mean developers should abdicate responsibility to something else. Applications should be robust, regardless, and a Web application firewall, if you decide you need one, is just extra precaution.

I talked to Jeremiah Grossman, CTO of White Security about application security at CSI and it was long ago and far away and I didn't take notes. But I do recall that he liked Web application firewalls because he said they do provide some protection against Web application attacks and when properly configured may give developers some breathing room to fix problems in applications. A point he made last year in "Let's Talk Web Application Firewalls (WAFs)."

I don't know if Web application firewalls are effective or not, nor do I know when they are likely to fail or not. From some of the chatter on the Web application security lists, the people who are up to their eyeballs in this topic can't even reach a consensus. Whether you use a Web application firewall is your decision, and you have to make that decision based on the threats you perceive and the effectiveness of the technology. But they are not a replacement for fixing problems in software.