Hello Ryan! > Additionally, we setup live proxy demos where we front-ended various web > app scanning vendor's public buggy apps (AppScan, WebInspect, etc...). Yes, your live proxy demos are more interesting, because they are based on live web applications. But there are still the same issue with them, as with CRS demo - they are at WAF's developer site and as I already told Josh, I'd never be checking my bypass techniques on own server of developer of WAF. So you need your WAF for IBM (AppScan) at demo.testfire.net, not modsecurity.org/demo.testfire.net/. Then it'll be suitable for me ;-). Or better put your WAF at vulnerable ibm.com, about holes at which I told IBM many times during 2007-2010 and they always ignored (and few times they lamerly and hiddenly fixed some holes long time after my informing), and which was hacked at begging of 2011. > As a side note - we need to upgrade the CRS... it is a rev or two behind. > Need to carve out some time to update it :) You just need to update your CRS more faster :-). And also you need to check your WAF, CRS and live demos not only to security issues, but also to bugs. Which there are in your demos (bugs I found the same quickly as holes). For example, there are bug with your WAF (which appears in its banner) concerns with two demo sites: modsecurity.org/demo.testfire.net/ and modsecurity.org/zero.webappsecurity.com. When visiting these sites the next message appears (at first time, when cookies is setting): "AppDefect: Missing HttpOnly Cookie Flag.." (in Outbound Alert). Beside removing second dot you need to take into account. That first site (demo.testfire.net) is setting HttpOnly flag for cookies (unlike second site), but your WAF doesn't see it. And I'm not even mentioning (to not make discussions about it) that such warning about HttpOnly flag I consider as not serious. So fix this bug with not seeing HttpOnly flag (if you decided to inform about it). Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ----- Original Message ----- From: "Rcbarnett" <rcbarnett@gmail.com> To: "Josh Amishav-Zlatin" <josh@ramat.cc> Cc: "MustLive" <mustlive@websecurity.com.ua>; "Michele Orru" <antisnatchor@gmail.com>; <websecurity@webappsec.org> Sent: Wednesday, January 19, 2011 7:53 PM Subject: Re: [WEB SECURITY] SQL Smuggling: New methods of SQL Smuggling On Jan 19, 2011, at 6:06 AM, Josh Amishav-Zlatin <josh@ramat.cc> wrote: > On Tue, Jan 18, 2011 at 11:34:45PM +0200, MustLive wrote: >> >> Regarding SQL Injection, then I've bypassed some time ModSecurity for >> SQLi >> attacks (as with using methods mentioned in my series of articles about >> SQL >> Smuggling, as with using other methods which will not be made public). >> Sometimes for full scale SQLi, sometimes for limited SQLi, but still >> useful >> for attacking purposes. I don't know about latest ModSecurity default >> rules, >> but you can give me a link to a site with such configuration and with SQL >> Injection holes :-), and I'll check it and will tell if any of my > > Hi, > > You can test your payloads against the ModSecurity Core Rule Set here: > http://www.modsecurity.org/demo/crs-demo.html > > You don't need the backend server to be vulnerable to SQLi, you only > want to check if the CRS identifies your payloads as malicious or not. > Additionally, we setup live proxy demos where we front-ended various web app scanning vendor's public buggy apps (AppScan, WebInspect, etc...). http://www.modsecurity.org/demo/ ModSecurity will not block but will prepend a banner to the top of the response to let you know if we flagged anything. This setup is more realistic vs our CRS demo that Josh referenced as you have a real app/db to interact with. As a side note - we need to upgrade the CRS... it is a rev or two behind. Need to carve out some time to update it :)

On Jan 31, 2011, at 2:14 PM, "MustLive" <mustlive@websecurity.com.ua> wrote: > Hello Ryan! > >> Additionally, we setup live proxy demos where we front-ended various web >> app scanning vendor's public buggy apps (AppScan, WebInspect, etc...). > > Yes, your live proxy demos are more interesting, because they are based on > live web applications. But there are still the same issue with them, as with > CRS demo - they are at WAF's developer site and as I already told Josh, I'd > never be checking my bypass techniques on own server of developer of WAF. > Umm... Why not? This response is the essence of breaker vs builder. ModSecurity is an open source project and the CRS is an OWASP Project. We have made enhancements to detection because the community helps test for evasions. Too bad you won't help with this... > So you need your WAF for IBM (AppScan) at demo.testfire.net, not > modsecurity.org/demo.testfire.net/. Then it'll be suitable for me ;-). Why would you send your payloads to a DAST vendor site and not an open source WAF site? > Or > better put your WAF at vulnerable ibm.com, about holes at which I told IBM > many times during 2007-2010 and they always ignored (and few times they > lamerly and hiddenly fixed some holes long time after my informing), and > which was hacked at begging of 2011. > >> As a side note - we need to upgrade the CRS... it is a rev or two behind. >> Need to carve out some time to update it :) > > You just need to update your CRS more faster :-). And also you need to check > your WAF, CRS and live demos not only to security issues, but also to bugs. > Which there are in your demos (bugs I found the same quickly as holes). > > For example, there are bug with your WAF (which appears in its banner) > concerns with two demo sites: modsecurity.org/demo.testfire.net/ and > modsecurity.org/zero.webappsecurity.com. > > When visiting these sites the next message appears (at first time, when > cookies is setting): "AppDefect: Missing HttpOnly Cookie Flag.." (in > Outbound Alert). Beside removing second dot you need to take into account. > That first site (demo.testfire.net) is setting HttpOnly flag for cookies > (unlike second site), but your WAF doesn't see it. And I'm not even > mentioning (to not make discussions about it) that such warning about > HttpOnly flag I consider as not serious. So fix this bug with not seeing > HttpOnly flag (if you decided to inform about it). > This warning is an app defect as httponly can help to protect cookies from xss. This alert simply informs the site owner about this. The banners are simply used in these demos as a mechanism to expose the ModSecurity alerts to the user. This is not how ModSecurity normally functions. -Ryan > Best wishes & regards, > MustLive > Administrator of Websecurity web site > http://websecurity.com.ua > > ----- Original Message ----- From: "Rcbarnett" <rcbarnett@gmail.com> > To: "Josh Amishav-Zlatin" <josh@ramat.cc> > Cc: "MustLive" <mustlive@websecurity.com.ua>; "Michele Orru" > <antisnatchor@gmail.com>; <websecurity@webappsec.org> > Sent: Wednesday, January 19, 2011 7:53 PM > Subject: Re: [WEB SECURITY] SQL Smuggling: New methods of SQL Smuggling > > > > On Jan 19, 2011, at 6:06 AM, Josh Amishav-Zlatin <josh@ramat.cc> wrote: > >> On Tue, Jan 18, 2011 at 11:34:45PM +0200, MustLive wrote: >>> >>> Regarding SQL Injection, then I've bypassed some time ModSecurity for >>> SQLi >>> attacks (as with using methods mentioned in my series of articles about >>> SQL >>> Smuggling, as with using other methods which will not be made public). >>> Sometimes for full scale SQLi, sometimes for limited SQLi, but still >>> useful >>> for attacking purposes. I don't know about latest ModSecurity default >>> rules, >>> but you can give me a link to a site with such configuration and with SQL >>> Injection holes :-), and I'll check it and will tell if any of my >> >> Hi, >> >> You can test your payloads against the ModSecurity Core Rule Set here: >> http://www.modsecurity.org/demo/crs-demo.html >> >> You don't need the backend server to be vulnerable to SQLi, you only >> want to check if the CRS identifies your payloads as malicious or not. >> > > Additionally, we setup live proxy demos where we front-ended various web app > scanning vendor's public buggy apps (AppScan, WebInspect, etc...). > > http://www.modsecurity.org/demo/ > > ModSecurity will not block but will prepend a banner to the top of the > response to let you know if we flagged anything. > > This setup is more realistic vs our CRS demo that Josh referenced as you > have a real app/db to interact with. > > As a side note - we need to upgrade the CRS... it is a rev or two behind. > Need to carve out some time to update it :) > >