Topics


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 On Walden's (very secure) Web
posted on Wednesday, June 25, 2008 5:18 AM

Andre Gironda (Dre) has declared war on WAF (Web Application Firewalls). I found his attack on WAFs a bit amusing because the belief that secure coding will take care of all web application vulnerabilities is quite utopian, and thus more compatible with a more passive-aggressive strategy and not a frontal assault with a war-declaring-gut-stomping-heated list of reasons to discount a technological solution to the problem of web application threat defense.

Today I'm going to focus on reason #2, because I don't believe it's peculiar to WAFs at all.

The "number 2" reason to wait on WAFs, according to Dre

Requires a web application security expert with code knowledge, HTTP knowledge, and a lot of time / careful planning to configure

I won't argue with the breadth of knowledge Dre claims is required to configure a WAF. Having configured WAFs in a previous life I don't find them to be as onerous as he makes them out to be, but I may be biased simply because I have most of the knowledge necessary to do so. So I won't belabor that point. Instead, I will point out that this list of requirements is eerily similar to those necessary for a developer to securely code an application. In other words, both a WAF and secure coding require many of the same skills and investment in order to implement properly.

In fact, I'd argue that developers need more skills and time than this to thoroughly protect a web application. In order to truly secure an application against vulnerabilities a developer would need:

  1. Specific language knowledge, to code against language level vulnerabilities 
  2. Expertise in frameworks/application server foundations, to code against vulnerabilities that might be introduced via a framework or the application server implementation
  3. OS knowledge, to guard against operating system level attacks that can be executed through a web application such as those that arbitrarily execute system level calls
  4. Database knowledge, to understand how SQL and specific database features might be exploited
  5. Compiler theory, to understand where stack- and memory-based vulnerabilities may exist
  6. HTML/CSS/DHTML knowledge, to protect against the myriad methods of exploiting the language and its delivery mechanisms 
  7. Network knowledge, to understand how TCP and HTTP might be exploited against an application
  8. Security expertise, so the developer knows how attacks are formulated/executed against web applications and how to defend against them
  9. Understanding of all relevant regulations (HIPAA, PCI DSS, SOX, BASEL II) and what needs to be implemented in code to achieve compliance
  10. Psychic powers, to anticipate new attack vectors and guard against them

I'd argue that Dre expects developers to be security, development, database, systems, regulatory, and network experts. And that's in addition to the requirement that developers understand and be experts in their particular organization's business. In addition to being able to code against the attacks, developers need to know how to launch the attacks, so they can test their solution to ensure it's working properly.

The primary argument against WAFs still appears to be that if developers only practiced more secure coding techniques, no other technological solution would be required, and certainly not WAFs. I don't necessarily disagree. If developers could guard against every attack, sanitized every input, and could anticipated potential and emerging attack vectors, we wouldn't need anything else to protect web applications.

But that scenario is simply a utopian dream, and is completely out of sync with reality. I grant it's a beautiful dream, like the one Thoreau had. But it is just that - a utopian dream.

On Walden's Web, developers have all the skills necessary to combat attackers. They are knowledgeable in a variety of attack methodologies and understand how to protect against all of them. Developers On Walden's Web have a deep understanding of compiler theory, and understanding where stack and memory vulnerabilities may exist - and how to prevent them. (I won't step up on my soap box and rail against the fact that most colleges are removing compiler theory from computer science degree programs.)

On Walden's Web, web application developers are masters of all trades: security, systems, language, web, database, regulatory, and networking experts. They understand the intricacies and delicate dance that occurs when an application is running and what might be exploited next so that they can code up the next solution.

Walden's Web is a beautiful, highly secure place. But like Walden's Pond, it exists only on paper. It is a utopian dream that cannot be achieved because the reality is that developers with all the necessary expertise do not exist in the numbers required, and have other responsibilities (coordination with business folks and needs, analysis, design, testing, maintenance, documentation) that often take precedence.

Neither WAFs nor secure coding are a panacea. Because of that, both should be employed in order to provide the broadest spectrum of defense against attacks.

At least until you can find and hire the developers from Walden's Web.

Imbibing: Coffee



 
      

Feedback


6/25/2008 8:40 AM
Gravatar Beautifully put.
It's probably easier to find one guy with # 10 than one with all the other 9...
deb

6/27/2008 1:16 PM
Gravatar I don't believe in secure coding. I believe that developers should write unit tests and integration unit tests that involve security properties. I think that any organization can immediately benefit from such practices, especially because integration unit testing can lower the 15% recidivism rate of security bugs in regression testing. I also like that unit tests can be used across projects in the same way that software re-use works (i.e. unit tests are re-usable source code and software components themselves).

Secure coding requires that developers are trained and know about security bugs, how to design around them, and all of the coding practices involved. Secure code review is also bad because it requires an expert to analyze tool results and perform taint propagation using data-flow and control-flow analysis, techniques usually reserved for only the best and brightest in the world of computer science.

I also find that security unit tests are superior to automated web application vulnerability scanners, because they are so close to the code and customized to the code as to avoid a slew of false positives and false negatives inherent in these kinds of commercial tools.

The role of the developer-tester is quickly replacing that of the normal "Software Quality Engineer" or the "bunch of kids we hired out of high school or McDonalds to test software like monkeys". Developer-testers are expected to be aware of base class libraries, third-party components (commercial and open-source), concepts of Cyclomatic complexity and code coverage (as well as other metrics and code-comprehension techniques), and class coupling issues such as the limitations of dependencies between libraries (which can be done with a variety of methods, including the ever-increasing popular Dependency injection and IoC container patterns, based originally on the Folwer Plugin pattern). They also write tests before code is written (instead of doing the QA after the application is already built), so that the tests can not only test for defects, but also simultaneously fix them. This is the future of software development everywhere, especially with web applications -- and I have seen it alive in many development shops, especially ones that utilize iterative programming, XP (or eXtreme programming), Agile, SCRUM, and even Waterfall (when Waterfall uses a Test-Driven Design -- or TDD -- pattern).
Andre Gironda
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 4 and 5 and type the answer here: