[WEB SECURITY] SQL Smuggling: New methods of SQL Smuggling
mustlive at websecurity.com.ua
Mon Jan 31 14:14:26 EST 2011
> 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
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,
Administrator of Websecurity web site
----- Original Message -----
From: "Rcbarnett" <rcbarnett at gmail.com>
To: "Josh Amishav-Zlatin" <josh at ramat.cc>
Cc: "MustLive" <mustlive at websecurity.com.ua>; "Michele Orru"
<antisnatchor at gmail.com>; <websecurity at 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 at 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
>> attacks (as with using methods mentioned in my series of articles about
>> Smuggling, as with using other methods which will not be made public).
>> Sometimes for full scale SQLi, sometimes for limited SQLi, but still
>> for attacking purposes. I don't know about latest ModSecurity default
>> 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
> You can test your payloads against the ModSecurity Core Rule Set here:
> 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...).
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 :)
More information about the websecurity