The Worry-Wart's Guide to Web Application Security
Six questions for Mike Andrews and James A. Whittaker
By Esther SchindlerHow to Break Web Software: Functional and Security Testing of Web Applications and Web Services, Mike Andrews and James A. Whittaker tackle every category of Web software exploit. They reveal where to look for potential threats and attack vectors, how to rigorously test for each of them, and how to mitigate the problems you find.
We found a few minutes to chat with these two experts, and to ask them for advice.
Mike Andrews is a senior consultant at Foundstone who leads the web application testing service lines. James Whittaker is a professor of computer science at Florida Tech, Founder of Security Innovation, and author of How to Break Software. He's also co-author of How to Break Software Security and How to Break Web Software.
1. You talk to a lot of developers who are interested in improving their site's security. But you probably worry more about the people who aren't thinking about it. What do you find the worry-warts are most likely to be concerned with? Are these the issues or technologies that are really the most common problems?
The two main things to worry about are network-layer penetration and, primarily, bugs in the application layer. The companies that really do worry about security are concerned with both. However, they also realize that they can't plug every hole. Thus, they spend a great deal of time thinking about what happens when a breach actually occurs.
An average web application processes and/or stores some real sensitive information: credit-card numbers, personal details (such as names, addresses, phone numbers), medical information, etc. Much of this information is protected through regulation or compliance policies -- a veritable alphabet soup of acronyms like HIPAA, PCI, SOX, GLBA, SB 1386, ISO17788, to name but a few -- which can impose severe financial penalties when the security of this information is compromised. To protect both the information and the company, there's a big effort to provide data segregation, so if there is a vulnerability and subsequent breach, the impact is minimized.
This diligence at prevention and planning for the worst is what separates the good companies from the bad.
2. What are the most common myths or assumptions about web site security?
That it's easy. That a developer who has read (and perhaps understood) an article or two about SQL injection or cross-site scripting can address these issues and that will make his application secure. These two vulnerabilities are certainly the most common at the moment, probably because they are comparatively simple to conduct and exploit. However, a whole raft of further vulnerabilities is waiting down the road; they just aren't being exploited at the moment, because there are easier attack vectors.
3. If you could convince every web developer to do one thing, just one thing to improve the site, what would it be?
It's got to be to validate inputs and outputs that flow to and from the web application.
If developers only validated their inputs to what they are expecting to be given, rather than attempting to filter for malicious inputs (if at all), then 80-90% of web application vulnerabilities would go away. SQL Injection -- gone, XSS -- gone, parameter tampering -- gone. For example, if the application is expecting a customer's US ZIP code, it should receive five to nine numbers, not 10,000 "A's" or punctuation characters, or HTML mark-up.
Likewise with outputs; you can't assume the "correctness" of all data, as perhaps it has come from a different system or an attack has managed to sneak it in somehow. However, data being outputted by the application is supposed to be just that, data, and therefore should be validated (or encoded) accordingly.