ESAPI Web Application Firewall released!
The ESAPI project is quickly gaining steam. We’ve added a number of strong committers and there are many companies out their adopting. My little addition to ESAPI was just released yesterday at OWASP AppSec DC, the ESAPI Web Application Firewall. Slides here.
You don’t need to implement the rest of ESAPI to use it, since it’s completely decoupled. It’s being published as part of ESAPI since virtual patches are an enterprise security need – and that’s what ESAPI is all about. The WAF was built for the Java version, but there’s nothing so specific to Java that would make it difficult to port to the other versions of ESAPI (assuming they have some BeanShell equivalent, which I think they all do).
What does the WAF offer? Well, a lot. It can stop all your normal injection attacks, like any WAF should. It’s closer architecturally to the application since it lives in a J2EE filter, and this allows it to do things a normal WAF can’t, like fix “business logic” vulnerabilities such as missing authentication or authorization.
It can also solve a number of “lesser” problems you’ll run into after a security assessment, like enforcing HTTPS, HTTP method restriction, or adding missing caching or content-type headers. You can also use it to perform fancy egress filtering, if you’re so inclined. All without touching a single line of code!
I can also make a strong case for performance, since the WAF doesn’t have to manage its own I/O or state, since that’s all handled by the application server. The performance hit, especially if you’re not doing any crazy egress stuff where response data must be buffered, is minimal.
Anyway, it does way more than blog post could do justice. Check out the policy file configuration guide or the JavaDocs, and keep the ESAPI mailing list in the loop on your integration experience!
It’s available for download now as part of ESAPI 2.0 RC4.
Erwin Geirnaert said,
Wrote on November 16, 2009 @ 4:10 am
Hi Arshan,
Where are the slides?
Best regards,
Erwin
arshan dabirsiaghi said,
Wrote on November 16, 2009 @ 10:32 am
updated the post, sorry!
Mr. Huddle: The Easiest Way To Keep Up With Your Communities said,
Wrote on November 18, 2009 @ 3:20 am
[...] | The-iBlog The-iBlog – Your source for iPhone and Apple news and help. 2 Likes ESAPI Web Application Firewall released! « omg.wtf.bbq. 2 Likes Yfrog – g0gm – Uploaded by rogueclown YFrog – Share your images and [...]
kuza55 said,
Wrote on December 17, 2009 @ 7:20 am
To be honest, the only part of a WAF I would be concerned about is egress filtering, it’s a little hard to test custom webapps without ever triggering an error. You could limit yourself to a subset of test you’re pretty sure wouldn’t cause an error and try to detect weird app behaviour, but that can be a pain.
The reason virtual patches don’t worry me so much is because the worst case is the attack gets blocked; I don’t lose my 0day in your webapp, because, well, you already know about it. Egress filtering & general rules mean I can be worse off than if you didn’t have a WAF and had just patched the vuln. Also, if there’s a WAF between me and the target, I’d bet on me getting through.
Also, your “Is criticism stupid?”-ometer should probably meet a friend of mine called reliable heap overflow. Seriously.
Obviously this isn’t so much of a problem for ESAPI as it is for other products, but it doesn’t make the criticism stupid.
arshan dabirsiaghi said,
Wrote on December 18, 2009 @ 9:17 am
I think you misunderstood our usage of egress filtering. A stateful “is-this-user-causing-problems” mechanism is more a theme to the AppSensor project, not the ESAPI WAF. Our usage of egress filtering is watching outbound data for known sensitive data formats, type-I XSS payloads, etc.
Yup RE: 0day still being present. Nope RE: better off. Most of the enterprises out there have serious lag time between time to discovery and time to fix. Even sometimes for high risk vulnerabilities I see 40+ days before a patch is delivered. And by the way, there’s no guarantee the patch actually fixes the problem and doesn’t introduce a new one.
RE: attack surface. At layer 8 I think we can firmly conclude that the WAF has the ability to remove more attack surface than it adds, assuming competent operation.
For commercial products operating at layer 6/7, they probably do add some limited attack surface, assuming they’re all built with native code. I also (possibly wrongly) assume they’re running on SELinux/grsecurity/Vista w/ ASLR&DEP/(closest equivalent for their OS). The cost of exploit development in a platform like that is higher than most classes of attackers can afford technically or financially. But anyway, there’s for other companies to deal with, it’s not a problem I have. =)
The WAF is for development teams mature in the world of application security. It’s strictly intended for virtual patches. Whether its used appropriately I can’t control.
The bottom line, to me, is that I would want this as an application owner. It gives me short term solutions that I didn’t have before.
kuza55 said,
Wrote on December 18, 2009 @ 8:11 pm
I have no issues with ESAPI in terms of attack surface, any addition is minimal IMO, but I would never want to put a WAF written in a memory unsafe language in front of a web application written in a memory safe language.
Also, I’d read this mail if I were you: http://lists.immunitysec.com/pipermail/dailydave/2009-August/005837.html
Even if writing a fuzzer->exploit is out of the range of the attackers you want to prevent, 2k USD is well within the range of someone who wants to make some $$/fuck some shit up, especially given who runs that WAF.
That device is hardened a little, but nowhere near as hardened as it should have been.