“Attackers are smart, you are not.” is a bad message

Dave G. | September 19th, 2006 | Filed Under: Uncategorized

Today I attended the Secure Software Forum’s Workshop in midtown manhattan. I would say it wasn’t particularly interesting for people who understand this stuff. They did the standard show us all the bad things:

  • Cardsystems, Guidance and Rhode Island compromises to ‘set the scene’.
  • Cross Site Scripting. Exactly what you think this is. Lots of time showing all the clever ways you can get lots of clever HTML/Javascript into someone’s browser.
  • SQL Injection. Also exactly what you would expect. Lots of time showing all the clever SQL you can execute.
  • Forced Browsing. and so on…

Lots. Lots. Lots. I think one of the bad things about this space is the amount of time we spend talking about all of the bad things that can happen as opposed to how a few things can prevent you from all of them. We show how clever attackers are. We basically set people up to think that they can’t really stop these attacks. And when you set up the problem as untenable, you reduce the likelihood that people will really try.

I did like the speaker’s approach to web app security. He distinguished between input validation (this happens first) and safe data handling (this happens second when it does happen). It is worth mentioning, because a lot of people write an input validation component and rely on it as an exclusive means of managing security.

It is kind of amazing that nothing has really changed in web application security over the course of a couple of years. And by amazing, I mean sad. A lot of this seemed new to the audience, who were all security or developer types.

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

Viewing 7 Comments

    • ^
    • v
    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
    • ^
    • v
    ...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...
    • ^
    • v
    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.
    • ^
    • v
    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. :)
    • ^
    • v
    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.
    • ^
    • v
    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.
    • ^
    • v
    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.

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus