The real effectiveness of current WAF
While thinking about the recently discussed PHP IDS and other similar Web application firewalls (WAF) like mod_security or mod_parmguard, it seemed to me that quite a lot of people aren't aware of how effective such solutions in fact are.
Basically I agree that diffrent layers of protection is always a good idea to get at least close to a status that can considered to be secure. That's why people even started thinking about WAF. Nevertheless these solutions are actually doomed to fail by design, or to phrase it more precisely they are simply not suitable for every underlying scripting language, e.g. Perl, Ruby, PHP - whatsoever.
The reason lies in the way they parse incoming HTTP requests. Although the latter might be conform to RFC defined standards, it is in fact different from the way HTTP parsers work in application / scripting languages. Because of these differences it's quite easy for an attacker to sniff malicious variables through a WAF like lets say mod_security. An example has been provided by Stefan Esser during the MOPB.
So unless a Web application firewall is implemented exclusively for a specific language, it is very likely to be insecure and therefore using them should be well considered.
7 Comments:
Because of these differences it's quite easy for an attacker to sniff malicious variables through a WAF like lets say mod_security. An example has been provided by Stefan Esser during the MOPB.
Very strong statement, but your main problem is that you mean the rules of a WAF (to which which this satement may apply). In other words: the problem is not the WAF itself, but how you have configured it. As usual it's simple to bypass bad configured systems.
So you blamed the wrong one (person or tool), IMHO.
Anonymous again ;-)
Anonymous, thanks again for thinking prior writing such silly accusations. As opposed to you, I'm neither blaming anyone nor do write weak-minded statements.
My accusation is that you blame the wrong object/subject: WAF instead its rules/configuration.
So reading prior writing would be the first step for you ;-)
Anyway, i.g. I agree that any kind of security device would be needless if the appplication is written proper .. it's the developers fault, as usual.
Anonymous.
"it's the developers fault, as usual." no no and agian NO - it's pretty obvious you aren't developer because otherwise you wouldn't say so.
a developer is usually a guy working under immense time pressure, urged to be top up-to-date about everything around webapp or whatever-he-develops technology, constantly changing circumstances and practices and simply hasn't the time to read himself through webappsec blogs and forums a day.
It is "as usual" the fault of improper project management and it's lack of awareness what can be done with ajaxworms and javascript based attacks these days.
I've been in the exact position for years until i realized it sucks and rethought and now i am consulting developers and project owners in webapp security and the first thing i ALWAYS mention is: it's not your fault guys - you HAVE to maintain old crap, you HAVE to keep it running and add new features and parallely develop new applications and there's no way you can also be up-to-date on the immense field of security issues.
So to end my prayer - i don't wanna flame you - don't get me wrong - but i would really like to know what you do on the scenery? Are you developer? mamangement? security guy? How come you see the things as you tell?
Cheers,
.mario
I think it can be a great solution, but it all depends on the context it's used.
My main argument for it is very simple: if it can prevent more than doing wrong, I think it works in such situation.
I do have a strong feeling not to rely on it solely. Like use it in combination with a good IDS can be a great solution.
Anyway, it's hard to say something about it while not denying other methods.
Ronald
0x000000.com
I agree Ronald. The only restriction you have with layers is performance, which will of course slow down a bit by anything you add.
This posting is just meant as a kind of hint because I don't want developers to fall into a deceiving feeling of security.
FYI: Ivan Ristic, who is the author of mod_security, told me that he would intend to implement a sort of background personality to mod_security, which means that it then would try to act according to the underlying language.
If he does that correctly, I'll work but I'm not sure whether it's even possible to implement that for every existing language. Mistakes are likely to be made and so are security flaws.
Difficult thing ;)
and complexity leads to faultiness so i would always vote for chained but simple measurements with convention over configuration.
Post a Comment