Subject: RE: web appliaction security products (AKA application firewalls) - msg#00048

Previous Message by Date: click to view message preview

Metis 2.0 released

Here is the 2.0 release of Metis. This release finally support spidering Flash content and allow users to manage site data as they wish (see user documentation for webglobal options). Metis 2.0 is now available from : http://www.severus.org/sacha/metis Information ----------- This is a tool I wrote to collect information from web servers. This was written for the Open Source Security Testing Methodology (OSSTM) located on http://www.ideahamster.org/osstmm-description.htm. If you get OutOfMemory errors, it means that the site you are scanning is quite big and you need to grow the heap size by using the -Xms<size> option. By default, the metis.bat will set it to 150. This product includes modified software developed by Dmitry Skavish (skavish@xxxxxxx, http://www.flashgap.com/). Please read the user documentation in the doc directory. Changes -------- [ Changes in version 2.0 - 10-23-2002 ] - added support for Flash content - added new javascript handlers - added support for File I/O site info instead of memory (see webglobal option : use_file_io_for_spider_data) - added handling of new HTML tags - minor bug fix - added support for dynamic site element handling (see webglobal option : site_element_handler) Upcomming features ------------------------- - Distributed engin - Spider code licensing change to BSD for supporting other projects I'm working on and to answer to some commercial requests I had. - Better support for Javascript If you wish to contribute to this project, e-mail me at sacha@xxxxxxxxxxxx Requirements for compiling -------------------------- - HttpClient : http://jakarta.apache.org/commons/httpclient/ You need to replace the org.apache.commons.httpclient.methods.GetMethod class with the one supplided with the source of this program. - Sun JDK 1.4.0 or higher: http://java.sun.com ----------- Sacha Faust sacha@xxxxxxxxxxx

Next Message by Date: click to view message preview

Re: web appliaction security products (AKA application firewalls)

Hmm. Well, I personally think there are a few things that tools like Urlscan or stateful-inspection normalizing application proxies miss: o overflows and format strings in body variables o sql injection-type attacks o -number flaws All these sorts of attacks are perfectly valid HTTP, and you may want to prevent them on some pages, but not on others. So management of your restrictions is an issue. So my question is this: If I spent the few days it would take to port SPIKE Proxy over to an Application Proxy, would any of you actually use it? Theoretically you could set it up in front of your web server, optionally give it a certificate, and set up a file to tell it which variables have which restrictions (or you could use the default restrictions and individually relax them for certain variables). Any request that didn't fit the boundaries would just recieve an error message of some kind, and everything else would just get proxied through. Would anyone use this, or would it be a waste of a couple of days? -dave

Previous Message by Thread: click to view message preview

Re: web appliaction security products (AKA application firewalls)

2002-11-22-13:24:32 Jason Childers: > (5) Some tools require you to put them in "learning" mode so they > can "understand/recognize" what normal usage of your site is. In > my view, that's not a WAF security product... that's a smarter > IDS! I'd like to expand on this thought a little bit. A web proxy or other firewall component designed to improve security of webservers at the application level has to have some way of telling the difference between legitimate queries and attempts to burgle the server, perhaps via exploiting bugs. The tightest config you can get comes when you manually configure the proxy to precisely define what are legal queries, with very precise specifications for every one, including minimum/maximum lengths, numeric scale ranges, exact parameter formats, allowed alphabets, the whole schmeer. This requires duplicating the front-end scanning process of your webserver, replicating its specification in the config language of your application proxy. This amounts to a security code review, which is a good thing. It's also labor-intensive, some shops are unwilling to expend that labor. For such shops, a popular alternative is to have a proxy that can "train" to learn valid requests. The problem with this is that it's impossible for training to really teach such a proxy some details, e.g. the maximum permitted field lengths and permitted alphabets for various fields. So proxies that are configured only by training aren't going to be as strict as you can make a manually-configured parameter-checking proxy. > If your website changes, then you have to put the tool back in > learning mode - thereby exposing your website's security and your > infrastructure at known calculatable times. This concern I'm not completely in agreement with, however. It certainly applies in small "joe's bait shop and web hosting" type places, but serious shops have an intermediate stage between development and production, variously called quality assurance, or testing, or beta, or some such. This stage includes automated coverage testing, with automatic test suites that are carefully designed and maintained alongside the code to exercise every bit of it. If you're content with the weaker validity checking from training-configured proxies, you can train the new config in the qa pass, and push the updated config to the proxy servers along with the site update as part of the production release. -Bennett pgpIanfGtdEWL.pgp Description: PGP signature

Next Message by Thread: click to view message preview

Re: web appliaction security products (AKA application firewalls)

Hmm. Well, I personally think there are a few things that tools like Urlscan or stateful-inspection normalizing application proxies miss: o overflows and format strings in body variables o sql injection-type attacks o -number flaws All these sorts of attacks are perfectly valid HTTP, and you may want to prevent them on some pages, but not on others. So management of your restrictions is an issue. So my question is this: If I spent the few days it would take to port SPIKE Proxy over to an Application Proxy, would any of you actually use it? Theoretically you could set it up in front of your web server, optionally give it a certificate, and set up a file to tell it which variables have which restrictions (or you could use the default restrictions and individually relax them for certain variables). Any request that didn't fit the boundaries would just recieve an error message of some kind, and everything else would just get proxied through. Would anyone use this, or would it be a waste of a couple of days? -dave