Re: [WEB SECURITY] Fwd: [SC-L] OWASP Podcast #6: WAFs

[gaz Heyes <gazheyes@xxxxxxxxx>]

--00c09f9870575b4a8b046245b305
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

2009/2/6 Arian J. Evans <arian.evans@anachronic.com>

> BTW -- In this podcast you will find a glaringly apparent
> anti-WAF bias, which I myself used to have early on,
> before I figured out how to use them, and learned to
> ignore the more dishonest marketeers amongst them.
>
> The anti-WAF bias in the podcast is, amusingly, for the
> wrong reasons IMO, and shows an utter lack of experience
> or understanding of business needs/realities surrounding
> "secure code" and WAFs.
>
> WAFs *are* in a flux right now.
>
> They seem to work well on simple apps for binary syntax
> vulns (SQLi or not). They struggle on complex applications,
> particularly internationalized software, but mostly due to
> implementation issues (charsets, regional encoding support).
>
> They should work even better for many business logic vulns,
> but they don't (again due to implementation and usability
> limitations). Most folks I talk too that have been using WAFs
> for 1-2+ years are openly aware that they cannot protect
> simple business logic issues without explicit configuration
> and do not have the time to find and configure for things that
> the WAFs *could* easily be protecting.


I think there is a lack of interest of WAF vendors for actually securing
their products. I posted to the sla.ckers forum about WAF vendors giving us
some interaction, demos, filters, absolutely anything! I had no replies. My
interest is from a technical standpoint and to see if I could break any of
their systems but either they don't want to risk exposing their products or
they simply have no interest in making a better product.

I'd recommend every WAF vendor follows the same practice as PHPIDS and HTML
Purifier:-
http://demo.php-ids.org/
http://htmlpurifier.org/demo.php

Clear demo pages, somewhere to report flaws and some communication with the
security community.

WAF vendors change now before we lose interest:-
<http://sla.ckers.org/forum/read.php?21,24994>

Modsecurity where is your demo page exactly? :P

--00c09f9870575b4a8b046245b305
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2009/2/6 Arian J. Evans <span dir=3D"ltr">&lt;<a href=3D"mailto:arian.evans=
@anachronic.com">arian.evans@anachronic.com</a>&gt;</span><br><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"border-left: 1px s=
olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
BTW -- In this podcast you will find a glaringly apparent<br>
anti-WAF bias, which I myself used to have early on,<br>
before I figured out how to use them, and learned to<br>
ignore the more dishonest marketeers amongst them.<br>
<br>
The anti-WAF bias in the podcast is, amusingly, for the<br>
wrong reasons IMO, and shows an utter lack of experience<br>
or understanding of business needs/realities surrounding<br>
&quot;secure code&quot; and WAFs.<br>
<br>
WAFs *are* in a flux right now.<br>
<br>
They seem to work well on simple apps for binary syntax<br>
vulns (SQLi or not). They struggle on complex applications,<br>
particularly internationalized software, but mostly due to<br>
implementation issues (charsets, regional encoding support).<br>
<br>
They should work even better for many business logic vulns,<br>
but they don&#39;t (again due to implementation and usability<br>
limitations). Most folks I talk too that have been using WAFs<br>
for 1-2+ years are openly aware that they cannot protect<br>
simple business logic issues without explicit configuration<br>
and do not have the time to find and configure for things that<br>
the WAFs *could* easily be protecting.</blockquote><div><br>I think there i=
s a lack of interest of WAF vendors for actually
securing their products. I posted to the sla.ckers forum about WAF
vendors giving us some interaction, demos, filters, absolutely
anything! I had no replies. My interest is from a technical standpoint
and to see if I could break any of their systems but either they don&#39;t
want to risk exposing their products or they simply have no interest in
making a better product. <br>
<br>
I&#39;d recommend every WAF vendor follows the same practice as PHPIDS and =
HTML Purifier:-<br>
<a href=3D"http://demo.php-ids.org/";>http://demo.php-ids.org/</a><br>
<a href=3D"http://htmlpurifier.org/demo.php";>http://htmlpurifier.org/demo.p=
hp</a><br>
<br>
Clear demo pages, somewhere to report flaws and some communication with the=
 security community.&nbsp; <br><br>WAF vendors change now before we lose in=
terest:-<br>&lt;<a href=3D"http://sla.ckers.org/forum/read.php?21,24994";>ht=
tp://sla.ckers.org/forum/read.php?21,24994</a>&gt;<br>
<br>Modsecurity where is your demo page exactly? :P<br></div></div>

--00c09f9870575b4a8b046245b305--