Re: [WEB SECURITY] Re: Comparisons of Web ApplicationFirewalls

["Ivan Ristic" <ivan.ristic@xxxxxxxxx>]

As far as I know the ModSecurity detection mechanism (in w3af) does
not actually do anything.

I would say the following rules of thumb apply:

 - Passive or embedded WAFs cannot be detected when deployed in
non-blocking mode.

 - Reverse proxies (WAFs or not) can almost always be detected and
fingerprinted. (Not sure if one could detect an Apache reverse proxy
sitting in front of an Apache web server; I would have to try to be
sure.)

 - WAFs in blocking mode can be detected and almost certainly
fingerprinted. Here you would actually be fingerprinting the
configuration, probably not the products directly.


The bottom line is: configuration

On Tue, Jul 8, 2008 at 2:40 AM, Brian Shura <bshura@xxxxxxxxxxxxx> wrote:
> W3AF has a plug-in called "detectWAF" that tries to fingerprint WAFs.
>
> It currently attempts to detect URLScan, ModSecurity, and SecureIIS.
>
> http://w3af.sourceforge.net/pluginDesc.php#detectWAF
>
>
> Brian
>
> -----Original Message-----
> From: Jeremiah Grossman [mailto:jeremiah@xxxxxxxxxxxxxxx]
> Sent: Monday, July 07, 2008 6:25 PM
> To: Achim
> Cc: WASC Forum
> Subject: Re: [WEB SECURITY] Re: Comparisons of Web ApplicationFirewalls
>
>
> On Jul 7, 2008, at 3:56 PM, Achim wrote:
>
>>
>> !! Anyone want to make an open source WAF fingerprinter? :) Now
>> would be a great
>> !! time!
>>
>> LOL
>> which WAF cannot be identified by it's cookie --which are most
>> likely not
>> changed in the configuration, (un)fortunatelly?
>>
>>   1. ModSecurity (as it doesn't use cookies ;-)
>>   2. ..
>>   ..
>>
>>
>
>
>
> There should be a few ways in addition to cookies actually.
>
> Some of them encrypt or sign cookies, perhaps that could be
> fingerprinted if a consistent format could be identified. They also
> might respond consistently with particular malformed requests
> differently than a web server would. Response codes, length, or even
> an HTML error message. Some of them also scrub particular data types
> in the response like internal IPs, credit card numbers, etc. With a
> content spoofing vuln, these might be injected on the fly to see if
> they magically vanish.
>
> Just a few ideas. The tough part is getting a test-bed.
>
> Jeremiah-
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.4.6/1539 - Release Date: 7/7/2008
> 6:35 PM
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>



-- 
Ivan Ristic

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA