Are Secure Web Apps Possible? Yes (and no)

Mike Rothman wrote a post addressing the general problem of web security, titled "Are Secure Web Apps Possible?". My answer: Yes. And no. The general conclusion Mike comes to is that web scanners are useful for generating quick wins, but hardly complete. As long as they are used with that knowledge, they are excellent tools to have available.

He's absolutely right, but there are some problems with web application scanners. Well, "some" is an understatement. In traditional application testing, the attack surface is relatively small, and fairly well-defined. The rules for building a secure application haven't changed much in the last few years, and the basic language communicating with the hardware has been relatively stable for quite some time. At the very least, it's well-documented. The fact that we still have critical bugs popping up in common applications has more to do with the development process than the technology itself.

With web applications, it's not so simple. The platform is not the hardware. The platform is the web browser, and the web browser speaks hundreds of dialects, in dozens of languages, and they all interact. There are many more layers between the user and the hardware, and every one of them is exposed- to the network, to malicious users, to malicious servers, etc. The attack surface that presents is massive, but more importantly, it's dynamic. With new standards being added to the browsers, old ones being phased out, and the way that they interact changing constantly, creating a scanner that understands the context a web site runs in seems impossible. When you consider that there are about a dozen browsers currently in mainstream use (including mobile versions), the problem just compounds.

I don't expect web scanners to ever be able to address those problems, but I hope I'm wrong. Currently, it takes at least a few years of dedicated experience before you really get a "feel" for finding and assessing bugs, and RSnake doesn't scale well.

My opinion is that the fundamental architecture of the web needs to change drastically before it is even remotely close to "secure." Until then, all we can do is fix bugs, fix development processes, fix user behavior, or try to hack on kludges when the problems come up.

The last solution doesn't seem very helpful, so let's take a look at the other three.

Fortunately, in many cases, the subtle and obscure bugs aren't the problem. Security isn't black and white, and the trivial ones are easy to fix. If a company like AT&T hasn't at least found the simple issues (like the ones used in the recent so-called "hack"), they are being negligent. Mike is right, getting a few quick wins with a web scanner isn't a bad idea- just make sure you know what that means. You won't get everything, but you'll get the easy stuff, and this is where risk assessments really shine. That's a much bigger topic than this blog post can handle though.

Fixing development processes is just starting to catch on. Web developers, browser developers, and low-level system developers alike are beginning to adopt SDLs, and we're already seeing positive results. People are developing frameworks for secure development (more on that in future posts). Things are happening.

If development processes are hard to change, user behavior is next to impossible. Still, the truly paranoid user can expect a decent level of security through careful system configuration, limited browser functionality and general security awareness.

The general conclusion, something we all know, is that security is an extremely difficult, complex process. Many facets are involved, but each can only be addressed by a specific party. It's each of their responsibility to help all of us.