DISQUS

Christofer Hoff · 3 years ago

My question is, why aren’t web application firewalls as commonly deployed as traditional firewalls?

...Because they cost money that people could otherwise spend attending conferences on XSS and SQL injection...

...that and most of them actually require you to understand the applications (ha!) you are protecting in order to rationalize remediating the attacks against them.

PLUS, there's a (welcome and needed) convergence of XSG (XML Security Gateways,) traditional WA Firewalls and content/database protection occuring that people who have been burned by the first generation of WAF's are waiting to mature.

/Hoff

dre · 3 years ago

...why aren’t web application firewalls as commonly deployed as traditional firewalls?

because cisco and juniper don't market them. because check point's web intelligence causes applications to break and developers/managers don't see the point in fixing them. because products like f5 trafficshield and others have their own vulernabilities (see hacking exposed web applications, 2nd ed).

some smart people do implement software-based web application firewals such as eeye's secureiis and apache's mod_security. i found a great resource for mod_security rules at http://www.gotroot.com/tiki-index.php?page=mod_...

unfortunately, prevention for users means either a) turning off javascript and images or b) not using a browser. neither of these are realistic. i do a little more than the basics, and run firefox (consistent across all OSes) in -safe-mode as an unprivledged user. i also uncheck "saved forms" and "remember passwords" and everything under "content -> advanced javascript" settings. then, in about:config i change all the dom.disable_window_open* settings to true and network.enableIDN to false. maybe these should be defaults. on a mac, i often use camino (because it's faster) and can implement the same policies. under windows mobile, minimo has a lot of these options as well.

keeping up-to-date is important... windizupdate.com and firefox's automatic update features make a good combination if you're running windows xp. mac os x users obviously need to run software update often. certain packages like openssl need to be updated occasionally - like NOW... cygwin hasn't updated their packages yet, but this site has version 0.9.8c http://www.shininglightpro.com/products/Win32Op...

Mark Curphey · 3 years ago

Because they can only stop a very limited set of the attacks. They are (by definition) essentially glorified data validation filters. As such they have a very limited set of issues they can feasibly look for and protect against.

What happens when a developer uses ROT13 to store credit cards in cookies?

Architecturally you need to have control over the "context" of the data validation as well or you will suffer from massive false positive and negative.

I firmly believe the right place is in the framework, ie .NET and the JVM and not on the wire. ASP.NET in fact has this bult into the architecture in what is (badly) called an HTTP module.

You just can't apply network security technology and techniques (communication protocols based) to the software security software problem and have a decent coverage in the way you could with traditional firewalls.

I have a collection of design flaws and implementation bugs that no web app firewall would ever protect against.

Richard Bejtlich · 3 years ago

I think the complexity or at least the size of the attack and vulnerability set is beginning to overwhelm the capacity of many security shops. They can't keep up. Many security managers are completely out of touch with modern attacks. They are stuck in the days when buffer overflows were novel.

The best approach may be exposing the defenders to these attacks through conferences like Black Hat and CanSecWest, and blogs like Matasano Chargen, of course. :)

William · 3 years ago

Some companies attempted a deployment of application layer firewalls early in their existence only to be disappointed with performance, and in my case have them turn into a dead box during an DDOS attack.

If you have the staff with the skills necessary to implement GRSecurity full RBAC control on all your web facing machines you can limit your exposure to holes that would allow remote execution of code, which is obviously the most dangerous type of application vulnerability. This will not prevent information leakage via SQL Injection, or the ever present XSS attack, however you have mitigated the more serious problems, and you can use... i can't believe im saying this... training on secure application development. PHEW!! That was hard to get out.

Thomas Ptacek · 3 years ago

It's a good point re: performance, although I see a definite trend (let's call it the "Chicago School of Network Security") towards deploying standard sockets-based app proxies on critical aggregation points.

Regarding defending the OS vs. SQL injection attacks, I think this is a pretty big mistake. The problem is the insecure code, not the platform. I think old school security people (I definitely count myself among them) have a damaging bias for platform security and against "simple" things like XSS, when in fact XSS is the far more dangerous problem.

Chris_B · 3 years ago

Truth is that the HTTP protocol is such a dogs breakfast that if you put up a gateway that interprets strictly it *will* end up breaking something. Right now I'm stuck between a certain http security appliance vendor and a server team about to battle over whose fault it is that the app doesnt work.