mod-security-users — General discussion about mod_security

Re: [mod-security-users] MTOM

[Victor H. <vic...@gm...>]

I think this might be a limitation with libXML itself rather than
ModSecurity. See :

https://github.com/SpiderLabs/ModSecurity/issues/435#issuecomment-26547619
https://github.com/SpiderLabs/ModSecurity/issues/902

If this is still an issue you may consider following up on #902 with the
results of your testing there.

On Thu, Jul 19, 2018 at 4:16 PM Eric J. Bielski <eri...@gr...>
wrote:

> Greetings.
>
> Has there been any work done for MTOM through ModSecurity? Currently, the
> ModSecurity WAF must be disabled for any services running MTOM due to a
> conflict with line 44 of the modsecurityon configuration file. Line 44
> refers to blocking requests above a certain size.
>
> NGINX support has told me that ModSecurity does not support. They offer no
> further insight other than directing me to this forum.
>
> Any help is appreciated! Thank you.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>


-- 
-
Victor Ribeiro Hora

[mod-security-users] MTOM

[Eric J. B. <eri...@gr...>]

Greetings.

Has there been any work done for MTOM through ModSecurity? Currently, the
ModSecurity WAF must be disabled for any services running MTOM due to a
conflict with line 44 of the modsecurityon configuration file. Line 44
refers to blocking requests above a certain size.

NGINX support has told me that ModSecurity does not support. They offer no
further insight other than directing me to this forum.

Any help is appreciated! Thank you.

Re: [mod-security-users] Modsecurity 3 logging issues

[Victor H. <vic...@gm...>]

You are probably using an old version of libModSecurity.

SecAuditLogFormat should be supported since the commit below from
October/2017:

https://github.com/SpiderLabs/ModSecurity/commit/63bef3d142b2ae25ed42d344c40729fb5f3d552e

You should be running at least the latest official release (3.0.2). But if
you are upgrading your version ModSecurity, it's worth noting that the
current code on master has a number of recommended fixes that will be
getting into the an eventual 3.0.3 release. So please update your codebase,
recompile libModSecurity and you it should be fine :)

If the issue persists, you're welcome to open an issue on GitHub by
providing as much info as possible for further investigation.

Thanks.

On Fri, Jul 13, 2018 at 1:12 PM Dino Edwards <din...@my...>
wrote:

> I can’t get it to compile with the following switch:
>
>
>
> --with-yajl
>
>
>
> I get the following error:
>
>
>
> ./configure: error: invalid option "--with-yajl
>
>
>
> According to the article below, JSON support is already built-in and
> switching to concurrent should use JSON by default. It also says that
> SecAuditLogFormat is not supported.
>
>
>
>
>
> https://github.com/SpiderLabs/ModSecurity/issues/1483
>
>
>
> Am I missing something here?
>
>
>
> Thanks
>
>
>
>
>
>
>
> *From:* Victor Hora [mailto:vic...@gm...]
> *Sent:* Thursday, July 12, 2018 4:46 PM
> *To:* mod...@li...
> *Subject:* Re: [mod-security-users] Modsecurity 3 logging issues
>
>
>
> Yes, you need JSON support for saving logs in JSON format. JSON support is
> provided through the YAJL library, if the lib is installed on your system
> the configure script should automatically enable JSON support for you.
>
>
>
> Depending on your distro the packages are usually named "yajl" and
> "yajl-devel" or "libyajl" and "libyajl-devel". You could also use the
> "--with-yajl" option to specify a local/manual installation of YAJL.
>
> See compilation recipes for more info:
> https://github.com/SpiderLabs/ModSecurity/wiki/Compilation-recipes-for-v3.x
>
>
>
> You need to specify the "SecAuditLogFormat" directive to "JSON". It
> defaults to the native non-JSON format if you don't manually specify it.
>
> Also, if I remember correctly, you also need to specify the SecAuditLog
> directive to where the index of your Audit logs will be saved when using
> "Concurrent" logging.
>
>
>
>
>
>
>
> On Wed, Jul 11, 2018 at 5:37 PM Dino Edwards <
> din...@my...> wrote:
>
> I’m trying to get modsecurity to start logging audit events in JSON format
> so that I can import to ELK but I cannot get it to work. Here’s the
> relevant config:
>
>
>
> SecAuditEngine on
>
> SecAuditLogRelevantStatus "^[0-9]+"
>
> SecAuditLogParts ABIJDEFHZ
>
> SecAuditLogType concurrent
>
> #SecAuditLog /var/log/modsec_audit.log
>
> SecAuditLogStorageDir /usr/local/nginx/logs/modsecurity/domain.tld
>
>
>
> After I reload nginx I don’t see any files being generated in the
> /usr/local/nginx/logs/modsecurity/domain.tld directory.
>
>
>
> Can someone help point me in the right direction? Do I need to compile
> modsecurity with JSON support? If so, how would I go about doing that? I
> was under the impression that using SecAuditLogType concurrent would take
> care of it.
>
>
>
> Thanks in advance
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>
>
>
> --
>
> -
> Victor Ribeiro Hora
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>


-- 
-
Victor Ribeiro Hora

Re: [mod-security-users] Modsecurity 3 logging issues

[William C. <wil...@mu...>]

I had a similar issue with yajl and ModSec 3.0.2.
To work around, I pointed to our local build of it directly, for example
  --with-yajl=<full path to where ever>/yajl

But there is also an issue that
YAJL_LDFLAGS is not used when it builds test dir.
Work around is unwind <full path to where ever>/yajl/lib
into (CentOS) /lib64).

Hope that helps - Jay

On Fri, Jul 13, 2018 at 12:08 PM, Dino Edwards <
din...@my...> wrote:

> I can’t get it to compile with the following switch:
>
>
>
> --with-yajl
>
>
>
> I get the following error:
>
>
>
> ./configure: error: invalid option "--with-yajl
>
>
>
> According to the article below, JSON support is already built-in and
> switching to concurrent should use JSON by default. It also says that
> SecAuditLogFormat is not supported.
>
>
>
>
>
> https://github.com/SpiderLabs/ModSecurity/issues/1483
>
>
>
> Am I missing something here?
>
>
>
> Thanks
>
>
>
>
>
>
>
> *From:* Victor Hora [mailto:vic...@gm...]
> *Sent:* Thursday, July 12, 2018 4:46 PM
> *To:* mod...@li...
> *Subject:* Re: [mod-security-users] Modsecurity 3 logging issues
>
>
>
> Yes, you need JSON support for saving logs in JSON format. JSON support is
> provided through the YAJL library, if the lib is installed on your system
> the configure script should automatically enable JSON support for you.
>
>
>
> Depending on your distro the packages are usually named "yajl" and
> "yajl-devel" or "libyajl" and "libyajl-devel". You could also use the
> "--with-yajl" option to specify a local/manual installation of YAJL.
>
> See compilation recipes for more info: https://github.com/
> SpiderLabs/ModSecurity/wiki/Compilation-recipes-for-v3.x
>
>
>
> You need to specify the "SecAuditLogFormat" directive to "JSON". It
> defaults to the native non-JSON format if you don't manually specify it.
>
> Also, if I remember correctly, you also need to specify the SecAuditLog
> directive to where the index of your Audit logs will be saved when using
> "Concurrent" logging.
>
>
>
>
>
>
>
> On Wed, Jul 11, 2018 at 5:37 PM Dino Edwards <
> din...@my...> wrote:
>
> I’m trying to get modsecurity to start logging audit events in JSON format
> so that I can import to ELK but I cannot get it to work. Here’s the
> relevant config:
>
>
>
> SecAuditEngine on
>
> SecAuditLogRelevantStatus "^[0-9]+"
>
> SecAuditLogParts ABIJDEFHZ
>
> SecAuditLogType concurrent
>
> #SecAuditLog /var/log/modsec_audit.log
>
> SecAuditLogStorageDir /usr/local/nginx/logs/modsecurity/domain.tld
>
>
>
> After I reload nginx I don’t see any files being generated in the
> /usr/local/nginx/logs/modsecurity/domain.tld directory.
>
>
>
> Can someone help point me in the right direction? Do I need to compile
> modsecurity with JSON support? If so, how would I go about doing that? I
> was under the impression that using SecAuditLogType concurrent would take
> care of it.
>
>
>
> Thanks in advance
>
>
>
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>
>
>
> --
>
> -
> Victor Ribeiro Hora
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>

Re: [mod-security-users] Modsecurity 3 logging issues

[Dino E. <din...@my...>]

I can’t get it to compile with the following switch:

--with-yajl

I get the following error:

./configure: error: invalid option "--with-yajl

According to the article below, JSON support is already built-in and switching to concurrent should use JSON by default. It also says that SecAuditLogFormat is not supported.


https://github.com/SpiderLabs/ModSecurity/issues/1483

Am I missing something here?

Thanks



From: Victor Hora [mailto:vic...@gm...]
Sent: Thursday, July 12, 2018 4:46 PM
To: mod...@li...
Subject: Re: [mod-security-users] Modsecurity 3 logging issues

Yes, you need JSON support for saving logs in JSON format. JSON support is provided through the YAJL library, if the lib is installed on your system the configure script should automatically enable JSON support for you.

Depending on your distro the packages are usually named "yajl" and "yajl-devel" or "libyajl" and "libyajl-devel". You could also use the "--with-yajl" option to specify a local/manual installation of YAJL.
See compilation recipes for more info: https://github.com/SpiderLabs/ModSecurity/wiki/Compilation-recipes-for-v3.x

You need to specify the "SecAuditLogFormat" directive to "JSON". It defaults to the native non-JSON format if you don't manually specify it.
Also, if I remember correctly, you also need to specify the SecAuditLog directive to where the index of your Audit logs will be saved when using "Concurrent" logging.



On Wed, Jul 11, 2018 at 5:37 PM Dino Edwards <din...@my...<mailto:din...@my...>> wrote:
I’m trying to get modsecurity to start logging audit events in JSON format so that I can import to ELK but I cannot get it to work. Here’s the relevant config:

SecAuditEngine on
SecAuditLogRelevantStatus "^[0-9]+"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType concurrent
#SecAuditLog /var/log/modsec_audit.log
SecAuditLogStorageDir /usr/local/nginx/logs/modsecurity/domain.tld

After I reload nginx I don’t see any files being generated in the /usr/local/nginx/logs/modsecurity/domain.tld directory.

Can someone help point me in the right direction? Do I need to compile modsecurity with JSON support? If so, how would I go about doing that? I was under the impression that using SecAuditLogType concurrent would take care of it.

Thanks in advance



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
mod-security-users mailing list
mod...@li...<mailto:mod...@li...>
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/


--
-
Victor Ribeiro Hora

Re: [mod-security-users] Modsecurity 3 logging issues

[Victor H. <vic...@gm...>]

Yes, you need JSON support for saving logs in JSON format. JSON support is
provided through the YAJL library, if the lib is installed on your system
the configure script should automatically enable JSON support for you.

Depending on your distro the packages are usually named "yajl" and
"yajl-devel" or "libyajl" and "libyajl-devel". You could also use the
"--with-yajl" option to specify a local/manual installation of YAJL.
See compilation recipes for more info:
https://github.com/SpiderLabs/ModSecurity/wiki/Compilation-recipes-for-v3.x

You need to specify the "SecAuditLogFormat" directive to "JSON". It
defaults to the native non-JSON format if you don't manually specify it.
Also, if I remember correctly, you also need to specify the SecAuditLog
directive to where the index of your Audit logs will be saved when using
"Concurrent" logging.



On Wed, Jul 11, 2018 at 5:37 PM Dino Edwards <din...@my...>
wrote:

> I’m trying to get modsecurity to start logging audit events in JSON format
> so that I can import to ELK but I cannot get it to work. Here’s the
> relevant config:
>
>
>
> SecAuditEngine on
>
> SecAuditLogRelevantStatus "^[0-9]+"
>
> SecAuditLogParts ABIJDEFHZ
>
> SecAuditLogType concurrent
>
> #SecAuditLog /var/log/modsec_audit.log
>
> SecAuditLogStorageDir /usr/local/nginx/logs/modsecurity/domain.tld
>
>
>
> After I reload nginx I don’t see any files being generated in the
> /usr/local/nginx/logs/modsecurity/domain.tld directory.
>
>
>
> Can someone help point me in the right direction? Do I need to compile
> modsecurity with JSON support? If so, how would I go about doing that? I
> was under the impression that using SecAuditLogType concurrent would take
> care of it.
>
>
>
> Thanks in advance
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>


-- 
-
Victor Ribeiro Hora

[mod-security-users] Reporting from the CRS Community Summit

[Christian F. <chr...@ne...>]

Hi there,

I just finished a first blog post about the CRS community summit we ran last
week in London.

https://coreruleset.org/20180712/reporting-from-the-first-crs-community-summit-in-london/

More to come.

Christian

-- 
https://www.feistyduck.com/training/modsecurity-training-course
https://www.feistyduck.com/books/modsecurity-handbook/
mailto:chr...@ne...
twitter: @ChrFolini

[mod-security-users] Modsecurity 3 logging issues

[Dino E. <din...@my...>]

I'm trying to get modsecurity to start logging audit events in JSON format so that I can import to ELK but I cannot get it to work. Here's the relevant config:

SecAuditEngine on
SecAuditLogRelevantStatus "^[0-9]+"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType concurrent
#SecAuditLog /var/log/modsec_audit.log
SecAuditLogStorageDir /usr/local/nginx/logs/modsecurity/domain.tld

After I reload nginx I don't see any files being generated in the /usr/local/nginx/logs/modsecurity/domain.tld directory.

Can someone help point me in the right direction? Do I need to compile modsecurity with JSON support? If so, how would I go about doing that? I was under the impression that using SecAuditLogType concurrent would take care of it.

Thanks in advance

Re: [mod-security-users] Modsecurity 3.X Web Console

[Chaim S. <ch...@ch...>]

None actively supported Moodyy folks just use the ELK stack

On Tue, Jul 10, 2018, 11:58 AM Dino Edwards <din...@my...>
wrote:

> Hello all,
>
>
>
> Is there a web based console for managing Modsecurity 3.x and/or viewing
> alerts? I found waf-fle however I didn’t see any mention of support for
> modsecurity 3.x and it doesn’t look like it has been updated since 2014.
>
>
>
> Thanks
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>

[mod-security-users] Modsecurity 3.X Web Console

[Dino E. <din...@my...>]

Hello all,

Is there a web based console for managing Modsecurity 3.x and/or viewing alerts? I found waf-fle however I didn't see any mention of support for modsecurity 3.x and it doesn't look like it has been updated since 2014.

Thanks

[mod-security-users] The OWASP ModSecurity Core Rule Set as Part of DevOps (CI Pipeline)

[Franziska B. <fra...@gm...>]

Hello,


If you'd like to know how the OWASP ModSecurity Core Rule Set can easily
and quickly be integrated into a DevOps pipeline,

and if you'd like to know how a developer gets fast feedback on whether her
applications's traffic does not trigger false positives after a code
change,

check out my new blog post on coreruleset.org:


https://coreruleset.org/20180619/the-core-rule-set-as-part-of-devops-ci-pipeline/


Best regards,

Franziska Bühler

Re: [mod-security-users] Getting a false positive with rule "GET or HEAD Request with Body Content" (id: 920170)

[Christian V. <cv...@it...>]

Thanks Christian and Robert,

Yes by now I’m using:
modesec 2.9.0 nginx refactoring
nginx version: openresty/1.9.7.4
OWASP_CRS/3.0.0

Until yesterday I was using OWASP_CRS/2.2.9 and everything was perfect and really fast but I want it to try the 3.0 because they are more complete, crs 2.2.9 version has missing many severity tags.

I know that modsec 3 with nginx connector is the new thing and we should use it, but by now I can’t and I would like to wait until more people use this new version and read more comments about it.

Anyway here there is a part of the debug log with logs associated to this rules (REQUEST-920-PROTOCOL-ENFORCEMENT.conf)
https://pastebin.com/wGxHZScq <https://pastebin.com/wGxHZScq>

In line Nº 14 catch the POST in REQUEST_LINE "POST /climbersoul/public/buscador HTTP/1.1”
And in line Nº 41 catch a GET from against REQUEST_METHOD. The funny thing that there is no GET method in that request.

If is related to a bug for the version that I’m using, well there is nothing much to do for me…
I have modified this rule to: SecRule REQUEST_LINE "@rx ^(?:GET|HEAD)$” and it works :), but is not a proper way I think…
I think I’m gonna exclude this rule globally and test a bit more to see how it works other wise I’m gonna go back to 2.2.9 rules and put the severity manually…

Thanks!
Chris.

> On Jun 13, 2018, at 5:43 PM, Robert Paprocki <rpa...@fe...> wrote:
> 
> Hey Christian/Christian,
> 
> It looks like you're using the legacy ModSecurity 2.9x hack with Nginx, based on the 'producer' line and form in your audit logs. This is a big no-no, for a number of reasons :) We would (very) strongly urge you to use the 3.x branch of ModSecurity (https://github.com/SpiderLabs/ModSecurity-nginx <https://github.com/SpiderLabs/ModSecurity-nginx>).
> 
> There could be a number of reasons for this tripping, like Nginx rewriting the request method as part of an internal redirect or some screwy memory/race condition bug, or possibly a problem with the SecRules parser (I've see this a lot in the Nginx 2.x hack), but it's not worth digging into at this point. 2.x ModSecurity on Nginx isn't supported and shouldn't be discussed further :)
> 
> On Wed, Jun 13, 2018 at 1:37 PM, Christian Folini <chr...@ne... <mailto:chr...@ne...>> wrote:
> Hi Christian,
> 
> Christian here too.
> 
> You are asking a Core Rule Set question, but the effect you are describing
> does indeed sound like a ModSec issue, so it seems only legit to pass over
> the CRS mailinglist and address the ModSec user list.
> 
> So you have a POST request that matches on a rule with the following
> constraint?
> 
> SecRule REQUEST_METHOD "@rx ^(?:GET|HEAD)$" ...
> 
> That sounds quite unbelievable.
> 
> 
> - What ModSec version are you running and on what webserver?
> - Could you raise the debug log level to 9 and give us the full debug log
>   for 920170?
> 
> That should clear things up or allow us to reproduce this misbehaviour. Thanks
> for the detailed payload. That's a very good base already.
> 
> Ahoj,
> 
> Christian
> 
> 
> On Wed, Jun 13, 2018 at 03:12:28AM -0400, Christian Varas wrote:
> > Hi, I’m getting a false positive with a particular rule in crs 3.0.2, the
> > rule block any request ( GET or HEAD) when the content-length is not a 0
> > digit or is empty.
> >
> > The problem that rule match any POST request too. I tried same regex
> > ^(?:GET|HEAD)$ in online tools but it doesn’t work, in sites like:
> > https://www.regextester.com/ <https://www.regextester.com/> <https://www.regextester.com/ <https://www.regextester.com/>> or
> > https://regex101.com/r/uO1vS2/5 <https://regex101.com/r/uO1vS2/5> <https://regex101.com/r/uO1vS2/5 <https://regex101.com/r/uO1vS2/5>> only works
> > if I remove the “$” character, ex: ^(?:GET|HEAD) but if use this regex in
> > the rule, I’m still getting the false positive…
> >
> > I always can exclude this rule, but I would like to fix it.
> >
> > Any help would be really appreciated!
> >
> > Post:
> >
> > POST /myapp/public/buscador HTTP/1.1 Host: www.myapp.com <http://www.myapp.com/> Connection:
> > keep-alive Content-Length: 146 Cache-Control: max-age=0 Origin:
> > https://www.myapp.com <https://www.myapp.com/> Upgrade-Insecure-Requests: 1 Content-Type:
> > application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Macintosh; Intel
> > Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87
> > Safari/537.36 Accept:
> > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
> > Referer: https://www.myapp.com/myapp/public/buscador <https://www.myapp.com/myapp/public/buscador> Accept-Encoding: gzip,
> > deflate, br Accept-Language: en-US,en;q=0.9,es;q=0.8 Cookie:
> > remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6InJ0T1MreDdTcFVHZnJ6eFFVUVJibVE9PSIsInZhbHVlIjoiOWVpdnlhXC9UY29Cclk3dDhmUUYxSzZ5bGRLMWExVzhuVTNXZUFrSW1LR2hGQnNEb0kxdXc4XC9lOWE2R1BXcGZtZWR0alJEbHA2R1JhSmpTbXBoSUp6enNMMnRMNEZFNXpVZytxYmN3c2lRMD0iLCJtYWMiOiI0YTdmMWE4Y2M0Y2E2YjY3MWEyNTRhZjNkM2RmNDhlMmFiYTExOWVmZmQ2OTYzYjRjOWE3M2Y0M2VlYzljODc1In0%3D;
> > XSRF-TOKEN=eyJpdiI6ImxZeDdKWTNuUE53R2RoaDhuTEptRlE9PSIsInZhbHVlIjoiM1RPd3AzU2F5RjhldmJLQmxwaWR2VFU3Z1Y5dUlTSDRrcmx3dkZ4dDMxekZEUkRnSVpTcG9wUXJqOHdEbHlTRlJ2V2hVVkRabFZEZ0M1a1JKSmxzOWc9PSIsIm1hYyI6IjZkMmFkODc3YmY1YWEwYWY2NjQ2YjhlZDEwZmExMDVlY2MyMzE1Y2JiNDI5ODcxMTA0OTYxMTdkNWQzODZkMWMifQ%3D%3D;
> >
> > myapp_session=eyJpdiI6Im5lTHJwWlZqZnpcL1lMWkJRZ2ZVbW9nPT0iLCJ2YWx1ZSI6IitBOWVtQ0djQzczaGRkMlc3ck1jWXg3YllGVlNFaTZ5NW1EbERDY29ER0w1MWFaR3IzcVArK1hlY2d0SXpzRVBlSWRhZ01mNUMzRXpkYlNreUpxR0lBPT0iLCJtYWMiOiJmZWEwNzQxZTQwYzI1NmQ5MzdmOTI2NGY4Y2UxNjI5ZDFlOGQxNjU5NmJhZDE2YzdiYTg4YzQ5ZWU4ODc3YmY1In0%3D
> >
> > Modsec info:
> >
> > Message: Access denied with code 403 (phase 2). Match of "rx ^0?$" against
> > "REQUEST_HEADERS:Content-Length" required. [file
> > "/opt/waf/nginx/etc/modsec_rules/www.myapp.com/enabled_rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf <http://www.myapp.com/enabled_rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf>"]
> > [line "271"] [id "920170"] [rev "1"] [msg "GET or HEAD Request with Body
> > Content."] [data "146"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"]
> > [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag
> > "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag
> > "OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ"] [tag "CAPEC-272"] Action:
> > Intercepted (phase 2) Apache-Handler: IIS Stopwatch: 1528871402000491 498451
> > (- - -) Stopwatch2: 1528871402000491 498451; combined=5145, p1=327, p2=4743,
> > p3=0, p4=0, p5=75, sr=20, sw=0, l=0, gc=0 Producer: ModSecurity for nginx
> > (STABLE)/2.9.0 (http://www.modsecurity.org/ <http://www.modsecurity.org/>); OWASP_CRS/3.0.2. <http://3.0.2./>  Server:
> > ModSecurity Standalone Engine-Mode: "ENABLED"
> >
> > Rule with issues:
> >
> > # Do not accept GET or HEAD requests with bodies
> >
> > # -=[ Rule Logic ]=- # This is a chained rule that first checks the Request
> > Method.  If it is a # GET or HEAD method, then it checks for the existence
> > of a Content-Length # header.  If the header exists and its payload is
> > either not a 0 digit or not # empty, then it will match.  # # -=[ References
> > ]=- # http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3> # SecRule
> > REQUEST_METHOD "^(?:GET|HEAD)$" \ "msg:'GET or HEAD Request with Body
> > Content.',\ severity:'CRITICAL',\ id:920170,\ ver:'OWASP_CRS/3.0.0',\
> > rev:'1',\ maturity:'9',\ accuracy:'9',\ phase:request,\ block,\
> > logdata:'%{matched_var}',\ t:none,\ tag:'application-multi',\
> > tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\
> > tag:'OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ',\ tag:'CAPEC-272',\ chain"
> > SecRule REQUEST_HEADERS:Content-Length "!^0?$"\ "t:none,\
> > setvar:'tx.msg=%{rule.msg}',\
> > setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
> > setvar:'tx.%{rule.id <http://rule.id/>}-OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ-%{matched_var_name}=%{matched_var}’"
> >
> >
> > Cheers!  Chris.
> 
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
> 
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li... <mailto:mod...@li...>
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users <https://lists.sourceforge.net/lists/listinfo/mod-security-users>
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/ <http://www.modsecurity.org/projects/commercial/rules/>
> > http://www.modsecurity.org/projects/commercial/support/ <http://www.modsecurity.org/projects/commercial/support/>
> 
> 
> --
> https://www.feistyduck.com/training/modsecurity-training-course <https://www.feistyduck.com/training/modsecurity-training-course>
> https://www.feistyduck.com/books/modsecurity-handbook/ <https://www.feistyduck.com/books/modsecurity-handbook/>
> mailto:chr...@ne... <mailto:chr...@ne...>
> twitter: @ChrFolini
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
> _______________________________________________
> mod-security-users mailing list
> mod...@li... <mailto:mod...@li...>
> https://lists.sourceforge.net/lists/listinfo/mod-security-users <https://lists.sourceforge.net/lists/listinfo/mod-security-users>
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/ <http://www.modsecurity.org/projects/commercial/rules/>
> http://www.modsecurity.org/projects/commercial/support/ <http://www.modsecurity.org/projects/commercial/support/>
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] Getting a false positive with rule "GET or HEAD Request with Body Content" (id: 920170)

[Robert P. <rpa...@fe...>]

Hey Christian/Christian,

It looks like you're using the legacy ModSecurity 2.9x hack with Nginx,
based on the 'producer' line and form in your audit logs. This is a big
no-no, for a number of reasons :) We would (very) strongly urge you to use
the 3.x branch of ModSecurity (
https://github.com/SpiderLabs/ModSecurity-nginx).

There could be a number of reasons for this tripping, like Nginx rewriting
the request method as part of an internal redirect or some screwy
memory/race condition bug, or possibly a problem with the SecRules parser
(I've see this a lot in the Nginx 2.x hack), but it's not worth digging
into at this point. 2.x ModSecurity on Nginx isn't supported and shouldn't
be discussed further :)

On Wed, Jun 13, 2018 at 1:37 PM, Christian Folini <
chr...@ne...> wrote:

> Hi Christian,
>
> Christian here too.
>
> You are asking a Core Rule Set question, but the effect you are describing
> does indeed sound like a ModSec issue, so it seems only legit to pass over
> the CRS mailinglist and address the ModSec user list.
>
> So you have a POST request that matches on a rule with the following
> constraint?
>
> SecRule REQUEST_METHOD "@rx ^(?:GET|HEAD)$" ...
>
> That sounds quite unbelievable.
>
>
> - What ModSec version are you running and on what webserver?
> - Could you raise the debug log level to 9 and give us the full debug log
>   for 920170?
>
> That should clear things up or allow us to reproduce this misbehaviour.
> Thanks
> for the detailed payload. That's a very good base already.
>
> Ahoj,
>
> Christian
>
>
> On Wed, Jun 13, 2018 at 03:12:28AM -0400, Christian Varas wrote:
> > Hi, I’m getting a false positive with a particular rule in crs 3.0.2, the
> > rule block any request ( GET or HEAD) when the content-length is not a 0
> > digit or is empty.
> >
> > The problem that rule match any POST request too. I tried same regex
> > ^(?:GET|HEAD)$ in online tools but it doesn’t work, in sites like:
> > https://www.regextester.com/ <https://www.regextester.com/> or
> > https://regex101.com/r/uO1vS2/5 <https://regex101.com/r/uO1vS2/5> only
> works
> > if I remove the “$” character, ex: ^(?:GET|HEAD) but if use this regex in
> > the rule, I’m still getting the false positive…
> >
> > I always can exclude this rule, but I would like to fix it.
> >
> > Any help would be really appreciated!
> >
> > Post:
> >
> > POST /myapp/public/buscador HTTP/1.1 Host: www.myapp.com Connection:
> > keep-alive Content-Length: 146 Cache-Control: max-age=0 Origin:
> > https://www.myapp.com Upgrade-Insecure-Requests: 1 Content-Type:
> > application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Macintosh;
> Intel
> > Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko)
> Chrome/67.0.3396.87
> > Safari/537.36 Accept:
> > text/html,application/xhtml+xml,application/xml;q=0.9,
> image/webp,image/apng,*/*;q=0.8
> > Referer: https://www.myapp.com/myapp/public/buscador Accept-Encoding:
> gzip,
> > deflate, br Accept-Language: en-US,en;q=0.9,es;q=0.8 Cookie:
> > remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=
> eyJpdiI6InJ0T1MreDdTcFVHZnJ6eFFVUVJibVE9PSIsInZhbHVlIjoiOWVp
> dnlhXC9UY29Cclk3dDhmUUYxSzZ5bGRLMWExVzhuVTNXZUFrSW1LR2hGQnNE
> b0kxdXc4XC9lOWE2R1BXcGZtZWR0alJEbHA2R1JhSmpTbXBoSUp6enNMMnRM
> NEZFNXpVZytxYmN3c2lRMD0iLCJtYWMiOiI0YTdmMWE4Y2M0Y2E2YjY3MWEy
> NTRhZjNkM2RmNDhlMmFiYTExOWVmZmQ2OTYzYjRjOWE3M2Y0M2VlYzljODc1In0%3D;
> > XSRF-TOKEN=eyJpdiI6ImxZeDdKWTNuUE53R2RoaDhuTEptRlE9PSIsInZhbHVlIjoiM1RP
> d3AzU2F5RjhldmJLQmxwaWR2VFU3Z1Y5dUlTSDRrcmx3dkZ4dDMxekZEUkRn
> SVpTcG9wUXJqOHdEbHlTRlJ2V2hVVkRabFZEZ0M1a1JKSmxzOWc9PSIsIm1h
> YyI6IjZkMmFkODc3YmY1YWEwYWY2NjQ2YjhlZDEwZmExMDVlY2MyMzE1Y2Ji
> NDI5ODcxMTA0OTYxMTdkNWQzODZkMWMifQ%3D%3D;
> >
> > myapp_session=eyJpdiI6Im5lTHJwWlZqZnpcL1lMWk
> JRZ2ZVbW9nPT0iLCJ2YWx1ZSI6IitBOWVtQ0djQzczaGRkMlc3ck1jWXg3Yl
> lGVlNFaTZ5NW1EbERDY29ER0w1MWFaR3IzcVArK1hlY2d0SXpzRVBlSWRhZ0
> 1mNUMzRXpkYlNreUpxR0lBPT0iLCJtYWMiOiJmZWEwNzQxZTQwYzI1NmQ5Mz
> dmOTI2NGY4Y2UxNjI5ZDFlOGQxNjU5NmJhZDE2YzdiYTg4YzQ5ZWU4ODc3YmY1In0%3D
> >
> > Modsec info:
> >
> > Message: Access denied with code 403 (phase 2). Match of "rx ^0?$"
> against
> > "REQUEST_HEADERS:Content-Length" required. [file
> > "/opt/waf/nginx/etc/modsec_rules/www.myapp.com/enabled_
> rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"]
> > [line "271"] [id "920170"] [rev "1"] [msg "GET or HEAD Request with Body
> > Content."] [data "146"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"]
> > [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag
> > "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag
> > "OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ"] [tag "CAPEC-272"] Action:
> > Intercepted (phase 2) Apache-Handler: IIS Stopwatch: 1528871402000491
> 498451
> > (- - -) Stopwatch2: 1528871402000491 498451; combined=5145, p1=327,
> p2=4743,
> > p3=0, p4=0, p5=75, sr=20, sw=0, l=0, gc=0 Producer: ModSecurity for nginx
> > (STABLE)/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.2.  Server:
> > ModSecurity Standalone Engine-Mode: "ENABLED"
> >
> > Rule with issues:
> >
> > # Do not accept GET or HEAD requests with bodies
> >
> > # -=[ Rule Logic ]=- # This is a chained rule that first checks the
> Request
> > Method.  If it is a # GET or HEAD method, then it checks for the
> existence
> > of a Content-Length # header.  If the header exists and its payload is
> > either not a 0 digit or not # empty, then it will match.  # # -=[
> References
> > ]=- # http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3 #
> SecRule
> > REQUEST_METHOD "^(?:GET|HEAD)$" \ "msg:'GET or HEAD Request with Body
> > Content.',\ severity:'CRITICAL',\ id:920170,\ ver:'OWASP_CRS/3.0.0',\
> > rev:'1',\ maturity:'9',\ accuracy:'9',\ phase:request,\ block,\
> > logdata:'%{matched_var}',\ t:none,\ tag:'application-multi',\
> > tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\
> > tag:'OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ',\ tag:'CAPEC-272',\
> chain"
> > SecRule REQUEST_HEADERS:Content-Length "!^0?$"\ "t:none,\
> > setvar:'tx.msg=%{rule.msg}',\
> > setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
> > setvar:'tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/
> INVALID_HREQ-%{matched_var_name}=%{matched_var}’"
> >
> >
> > Cheers!  Chris.
>
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/
> > http://www.modsecurity.org/projects/commercial/support/
>
>
> --
> https://www.feistyduck.com/training/modsecurity-training-course
> https://www.feistyduck.com/books/modsecurity-handbook/
> mailto:chr...@ne...
> twitter: @ChrFolini
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>

Re: [mod-security-users] Getting a false positive with rule "GET or HEAD Request with Body Content" (id: 920170)

[Christian F. <chr...@ne...>]

Hi Christian,

Christian here too. 

You are asking a Core Rule Set question, but the effect you are describing
does indeed sound like a ModSec issue, so it seems only legit to pass over
the CRS mailinglist and address the ModSec user list.

So you have a POST request that matches on a rule with the following
constraint?

SecRule REQUEST_METHOD "@rx ^(?:GET|HEAD)$" ...

That sounds quite unbelievable.


- What ModSec version are you running and on what webserver?
- Could you raise the debug log level to 9 and give us the full debug log
  for 920170?

That should clear things up or allow us to reproduce this misbehaviour. Thanks
for the detailed payload. That's a very good base already.

Ahoj,

Christian


On Wed, Jun 13, 2018 at 03:12:28AM -0400, Christian Varas wrote:
> Hi, I’m getting a false positive with a particular rule in crs 3.0.2, the
> rule block any request ( GET or HEAD) when the content-length is not a 0
> digit or is empty.
> 
> The problem that rule match any POST request too. I tried same regex
> ^(?:GET|HEAD)$ in online tools but it doesn’t work, in sites like:
> https://www.regextester.com/ <https://www.regextester.com/> or
> https://regex101.com/r/uO1vS2/5 <https://regex101.com/r/uO1vS2/5> only works
> if I remove the “$” character, ex: ^(?:GET|HEAD) but if use this regex in
> the rule, I’m still getting the false positive… 
> 
> I always can exclude this rule, but I would like to fix it.
> 
> Any help would be really appreciated! 
> 
> Post:
> 
> POST /myapp/public/buscador HTTP/1.1 Host: www.myapp.com Connection:
> keep-alive Content-Length: 146 Cache-Control: max-age=0 Origin:
> https://www.myapp.com Upgrade-Insecure-Requests: 1 Content-Type:
> application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Macintosh; Intel
> Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87
> Safari/537.36 Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
> Referer: https://www.myapp.com/myapp/public/buscador Accept-Encoding: gzip,
> deflate, br Accept-Language: en-US,en;q=0.9,es;q=0.8 Cookie:
> remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6InJ0T1MreDdTcFVHZnJ6eFFVUVJibVE9PSIsInZhbHVlIjoiOWVpdnlhXC9UY29Cclk3dDhmUUYxSzZ5bGRLMWExVzhuVTNXZUFrSW1LR2hGQnNEb0kxdXc4XC9lOWE2R1BXcGZtZWR0alJEbHA2R1JhSmpTbXBoSUp6enNMMnRMNEZFNXpVZytxYmN3c2lRMD0iLCJtYWMiOiI0YTdmMWE4Y2M0Y2E2YjY3MWEyNTRhZjNkM2RmNDhlMmFiYTExOWVmZmQ2OTYzYjRjOWE3M2Y0M2VlYzljODc1In0%3D;
> XSRF-TOKEN=eyJpdiI6ImxZeDdKWTNuUE53R2RoaDhuTEptRlE9PSIsInZhbHVlIjoiM1RPd3AzU2F5RjhldmJLQmxwaWR2VFU3Z1Y5dUlTSDRrcmx3dkZ4dDMxekZEUkRnSVpTcG9wUXJqOHdEbHlTRlJ2V2hVVkRabFZEZ0M1a1JKSmxzOWc9PSIsIm1hYyI6IjZkMmFkODc3YmY1YWEwYWY2NjQ2YjhlZDEwZmExMDVlY2MyMzE1Y2JiNDI5ODcxMTA0OTYxMTdkNWQzODZkMWMifQ%3D%3D; 
> 
> myapp_session=eyJpdiI6Im5lTHJwWlZqZnpcL1lMWkJRZ2ZVbW9nPT0iLCJ2YWx1ZSI6IitBOWVtQ0djQzczaGRkMlc3ck1jWXg3YllGVlNFaTZ5NW1EbERDY29ER0w1MWFaR3IzcVArK1hlY2d0SXpzRVBlSWRhZ01mNUMzRXpkYlNreUpxR0lBPT0iLCJtYWMiOiJmZWEwNzQxZTQwYzI1NmQ5MzdmOTI2NGY4Y2UxNjI5ZDFlOGQxNjU5NmJhZDE2YzdiYTg4YzQ5ZWU4ODc3YmY1In0%3D 
> 
> Modsec info:
> 
> Message: Access denied with code 403 (phase 2). Match of "rx ^0?$" against
> "REQUEST_HEADERS:Content-Length" required. [file
> "/opt/waf/nginx/etc/modsec_rules/www.myapp.com/enabled_rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"]
> [line "271"] [id "920170"] [rev "1"] [msg "GET or HEAD Request with Body
> Content."] [data "146"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"]
> [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag
> "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag
> "OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ"] [tag "CAPEC-272"] Action:
> Intercepted (phase 2) Apache-Handler: IIS Stopwatch: 1528871402000491 498451
> (- - -) Stopwatch2: 1528871402000491 498451; combined=5145, p1=327, p2=4743,
> p3=0, p4=0, p5=75, sr=20, sw=0, l=0, gc=0 Producer: ModSecurity for nginx
> (STABLE)/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.2.  Server:
> ModSecurity Standalone Engine-Mode: "ENABLED"
> 
> Rule with issues: 
> 
> # Do not accept GET or HEAD requests with bodies
> 
> # -=[ Rule Logic ]=- # This is a chained rule that first checks the Request
> Method.  If it is a # GET or HEAD method, then it checks for the existence
> of a Content-Length # header.  If the header exists and its payload is
> either not a 0 digit or not # empty, then it will match.  # # -=[ References
> ]=- # http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3 # SecRule
> REQUEST_METHOD "^(?:GET|HEAD)$" \ "msg:'GET or HEAD Request with Body
> Content.',\ severity:'CRITICAL',\ id:920170,\ ver:'OWASP_CRS/3.0.0',\
> rev:'1',\ maturity:'9',\ accuracy:'9',\ phase:request,\ block,\
> logdata:'%{matched_var}',\ t:none,\ tag:'application-multi',\
> tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\
> tag:'OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ',\ tag:'CAPEC-272',\ chain"
> SecRule REQUEST_HEADERS:Content-Length "!^0?$"\ "t:none,\
> setvar:'tx.msg=%{rule.msg}',\
> setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
> setvar:'tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ-%{matched_var_name}=%{matched_var}’" 
> 
> 
> Cheers!  Chris.

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/


-- 
https://www.feistyduck.com/training/modsecurity-training-course
https://www.feistyduck.com/books/modsecurity-handbook/
mailto:chr...@ne...
twitter: @ChrFolini

[mod-security-users] Getting a false positive with rule "GET or HEAD Request with Body Content" (id: 920170)

[Christian V. <cv...@it...>]

Hi, I’m getting a false positive with a particular rule in crs 3.0.2, the rule block any request ( GET or HEAD) when the content-length is not a 0 digit or is empty.

The problem that rule match any POST request too. I tried same regex ^(?:GET|HEAD)$ in online tools but it doesn’t work, in sites like: https://www.regextester.com/ <https://www.regextester.com/> or https://regex101.com/r/uO1vS2/5 <https://regex101.com/r/uO1vS2/5> only works if I remove the “$” character, ex: ^(?:GET|HEAD) but if use this regex in the rule, I’m still getting the false positive… 

I always can exclude this rule, but I would like to fix it.

Any help would be really appreciated! 

Post:

POST /myapp/public/buscador HTTP/1.1
Host: www.myapp.com
Connection: keep-alive
Content-Length: 146
Cache-Control: max-age=0
Origin: https://www.myapp.com
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://www.myapp.com/myapp/public/buscador
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,es;q=0.8 
Cookie: remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6InJ0T1MreDdTcFVHZnJ6eFFVUVJibVE9PSIsInZhbHVlIjoiOWVpdnlhXC9UY29Cclk3dDhmUUYxSzZ5bGRLMWExVzhuVTNXZUFrSW1LR2hGQnNEb0kxdXc4XC9lOWE2R1BXcGZtZWR0alJEbHA2R1JhSmpTbXBoSUp6enNMMnRMNEZFNXpVZytxYmN3c2lRMD0iLCJtYWMiOiI0YTdmMWE4Y2M0Y2E2YjY3MWEyNTRhZjNkM2RmNDhlMmFiYTExOWVmZmQ2OTYzYjRjOWE3M2Y0M2VlYzljODc1In0%3D; XSRF-TOKEN=eyJpdiI6ImxZeDdKWTNuUE53R2RoaDhuTEptRlE9PSIsInZhbHVlIjoiM1RPd3AzU2F5RjhldmJLQmxwaWR2VFU3Z1Y5dUlTSDRrcmx3dkZ4dDMxekZEUkRnSVpTcG9wUXJqOHdEbHlTRlJ2V2hVVkRabFZEZ0M1a1JKSmxzOWc9PSIsIm1hYyI6IjZkMmFkODc3YmY1YWEwYWY2NjQ2YjhlZDEwZmExMDVlY2MyMzE1Y2JiNDI5ODcxMTA0OTYxMTdkNWQzODZkMWMifQ%3D%3D; 

myapp_session=eyJpdiI6Im5lTHJwWlZqZnpcL1lMWkJRZ2ZVbW9nPT0iLCJ2YWx1ZSI6IitBOWVtQ0djQzczaGRkMlc3ck1jWXg3YllGVlNFaTZ5NW1EbERDY29ER0w1MWFaR3IzcVArK1hlY2d0SXpzRVBlSWRhZ01mNUMzRXpkYlNreUpxR0lBPT0iLCJtYWMiOiJmZWEwNzQxZTQwYzI1NmQ5MzdmOTI2NGY4Y2UxNjI5ZDFlOGQxNjU5NmJhZDE2YzdiYTg4YzQ5ZWU4ODc3YmY1In0%3D 

Modsec info:

Message: Access denied with code 403 (phase 2). Match of "rx ^0?$" against "REQUEST_HEADERS:Content-Length" required. [file "/opt/waf/nginx/etc/modsec_rules/www.myapp.com/enabled_rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "271"] [id "920170"] [rev "1"] [msg "GET or HEAD Request with Body Content."] [data "146"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ"] [tag "CAPEC-272"]
Action: Intercepted (phase 2)
Apache-Handler: IIS
Stopwatch: 1528871402000491 498451 (- - -)
Stopwatch2: 1528871402000491 498451; combined=5145, p1=327, p2=4743, p3=0, p4=0, p5=75, sr=20, sw=0, l=0, gc=0
Producer: ModSecurity for nginx (STABLE)/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.2.
Server: ModSecurity Standalone
Engine-Mode: "ENABLED"

Rule with issues: 

# Do not accept GET or HEAD requests with bodies

# -=[ Rule Logic ]=-
# This is a chained rule that first checks the Request Method.  If it is a
# GET or HEAD method, then it checks for the existence of a Content-Length
# header.  If the header exists and its payload is either not a 0 digit or not
# empty, then it will match.
#
# -=[ References ]=-
# http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3
#
SecRule REQUEST_METHOD "^(?:GET|HEAD)$" \
  "msg:'GET or HEAD Request with Body Content.',\
  severity:'CRITICAL',\
  id:920170,\
  ver:'OWASP_CRS/3.0.0',\
  rev:'1',\
  maturity:'9',\
  accuracy:'9',\
  phase:request,\
  block,\
  logdata:'%{matched_var}',\
  t:none,\
  tag:'application-multi',\
  tag:'language-multi',\
  tag:'platform-multi',\
  tag:'attack-protocol',\
  tag:'OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ',\
  tag:'CAPEC-272',\
  chain"
	SecRule REQUEST_HEADERS:Content-Length "!^0?$"\
	  "t:none,\
	  setvar:'tx.msg=%{rule.msg}',\
	  setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
	  setvar:'tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ-%{matched_var_name}=%{matched_var}’" 


Cheers!
Chris.

Re: [mod-security-users] libmodsecurity collection files location

[Ervin H. <ai...@gm...>]

Hi Ehsan,

I'm not sure, but the "expirevar" can helps you. You can find
many examples (not just for this issue) here:

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/

especially:

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/collection-resource.json#L50


Note, that I'm also not sure, but afraid that this function
("expirevar") doesn't work if the collection backend is LMDB.


HTH,



a.


On Tue, Jun 12, 2018 at 10:18:33AM +0430, Ehsan Mahdavi wrote:
> Hello Ervin,
> Thanks for your response.
> I think you are talking about the correct options. But to be more specific
> I need to reset the statistics collected about different source IP
> addresses. These statistics are used to determine IP:DOS_BLOCK and I need
> to reset them sometimes.
> In Modsecurity V2.x it was enough to delete some of those files.
> How Do I do this in V3.0?
> 
> regards
> 
> 
> 
> On Mon, Jun 11, 2018 at 2:28 PM Ervin Hegedüs <ai...@gm...> wrote:
> 
> > Hi Ehsan,
> >
> > On Mon, Jun 11, 2018 at 01:20:58PM +0430, Ehsan Mahdavi wrote:
> > > Hi all
> > >
> > > Modsecurity version 2 had some collection files like ip.pag, global.pag
> > and
> > > etc stored in  location specified by SecDataDir  .
> > > Migrating to modsec V3.0 I can't find such files there.
> > >
> > > Where should I be looking at?
> >
> > I've never used ModSecurity 2, but in V3, as I know (and if it's
> > analog what you describe above) there are two kinds of type of
> > collections:
> >
> > * in-memory
> > * lmdb
> >
> > See the source:
> >
> >
> > https://github.com/SpiderLabs/ModSecurity/blob/95048d5fcfe43147ab0269bff69e2353817cb7c7/src/modsecurity.cc#L65
> >
> > https://github.com/SpiderLabs/ModSecurity/tree/v3/master/src/collection/backend
> >
> > So, the in-memory backend stores the variables in memory, LMDB
> > stores in an LMDB database, therefore I'm afraid there aren't any
> > other files, what you're looking for.
> >
> >
> > Note, that the LMDB collection doesn't work in this state, the
> > patch are waiting for the merge:
> > https://github.com/SpiderLabs/ModSecurity/pull/1787
> >
> > But may be I'm wrong and you're talking about totally another
> > context of collections. :)
> >
> >
> >
> > a.
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/
> > http://www.modsecurity.org/projects/commercial/support/
> >

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] libmodsecurity collection files location

[Ehsan M. <ehs...@gm...>]

Hello Ervin,
Thanks for your response.
I think you are talking about the correct options. But to be more specific
I need to reset the statistics collected about different source IP
addresses. These statistics are used to determine IP:DOS_BLOCK and I need
to reset them sometimes.
In Modsecurity V2.x it was enough to delete some of those files.
How Do I do this in V3.0?

regards



On Mon, Jun 11, 2018 at 2:28 PM Ervin Hegedüs <ai...@gm...> wrote:

> Hi Ehsan,
>
> On Mon, Jun 11, 2018 at 01:20:58PM +0430, Ehsan Mahdavi wrote:
> > Hi all
> >
> > Modsecurity version 2 had some collection files like ip.pag, global.pag
> and
> > etc stored in  location specified by SecDataDir  .
> > Migrating to modsec V3.0 I can't find such files there.
> >
> > Where should I be looking at?
>
> I've never used ModSecurity 2, but in V3, as I know (and if it's
> analog what you describe above) there are two kinds of type of
> collections:
>
> * in-memory
> * lmdb
>
> See the source:
>
>
> https://github.com/SpiderLabs/ModSecurity/blob/95048d5fcfe43147ab0269bff69e2353817cb7c7/src/modsecurity.cc#L65
>
> https://github.com/SpiderLabs/ModSecurity/tree/v3/master/src/collection/backend
>
> So, the in-memory backend stores the variables in memory, LMDB
> stores in an LMDB database, therefore I'm afraid there aren't any
> other files, what you're looking for.
>
>
> Note, that the LMDB collection doesn't work in this state, the
> patch are waiting for the merge:
> https://github.com/SpiderLabs/ModSecurity/pull/1787
>
> But may be I'm wrong and you're talking about totally another
> context of collections. :)
>
>
>
> a.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>

Re: [mod-security-users] libmodsecurity collection files location

[Ervin H. <ai...@gm...>]

Hi Ehsan,

On Mon, Jun 11, 2018 at 01:20:58PM +0430, Ehsan Mahdavi wrote:
> Hi all
> 
> Modsecurity version 2 had some collection files like ip.pag, global.pag and
> etc stored in  location specified by SecDataDir  .
> Migrating to modsec V3.0 I can't find such files there.
> 
> Where should I be looking at?

I've never used ModSecurity 2, but in V3, as I know (and if it's
analog what you describe above) there are two kinds of type of
collections:

* in-memory
* lmdb

See the source:

https://github.com/SpiderLabs/ModSecurity/blob/95048d5fcfe43147ab0269bff69e2353817cb7c7/src/modsecurity.cc#L65
https://github.com/SpiderLabs/ModSecurity/tree/v3/master/src/collection/backend

So, the in-memory backend stores the variables in memory, LMDB
stores in an LMDB database, therefore I'm afraid there aren't any
other files, what you're looking for.


Note, that the LMDB collection doesn't work in this state, the
patch are waiting for the merge:
https://github.com/SpiderLabs/ModSecurity/pull/1787

But may be I'm wrong and you're talking about totally another
context of collections. :)



a.

[mod-security-users] libmodsecurity collection files location

[Ehsan M. <ehs...@gm...>]

Hi all

Modsecurity version 2 had some collection files like ip.pag, global.pag and
etc stored in  location specified by SecDataDir  .
Migrating to modsec V3.0 I can't find such files there.

Where should I be looking at?

Thank you all

[mod-security-users] Registration for the Core Rule Set community summit open

[Christian F. <chr...@ne...>]

Hello,

We have been planning to do an OWASP ModSecurity Core Rule Set community
summit at the upcoming AppSecEU conference in London. The program is still
in the making, but registrations is now open:

https://coreruleset.org/20180607/registration-open-for-the-crs-community-summit-on-july-4/

This is going to be on Wednesday July 4, at 4pm at the Queen Elisabeth II
Center in central London. We plan to talk about CRS, the recent proposal for
a rule Meta Language, roadmap of the project, your use cases and your burning
questions. Afterwards we plan to go out and eat / drink together and we are
very happy that cPanel agreed to sponsor that for us!

Please note, that you do not have to register for AppSecEU to participate
the our CRS summit.

If there are any questions or if you think you have something to contribute
to the program, then please get in touch with me directly.

Best regards,

Christian Folini


-- 
https://www.feistyduck.com/training/modsecurity-training-course
https://www.feistyduck.com/books/modsecurity-handbook/
mailto:chr...@ne...
twitter: @ChrFolini

Re: [mod-security-users] Language Bindings for libmodsecurity/ModSecurity v3

[Osama E. <oel...@gm...>]

Great.  Thanks.

-- 
Osama Elnaggar

On June 8, 2018 at 10:04:14 AM, Robert Paprocki (
rpa...@fe...) wrote:



On Thu, Jun 7, 2018 at 3:26 PM, Osama Elnaggar <oel...@gm...>
wrote:

> Thank Robert.  I remember the discussion + the useful benchmarks you and
> others shared
>
> The FaaS model is different from your high performance proxy model as FaaS
> basically runs a single concurrent request per container (with the
> containers scaling to accommodate additional incoming requests) so adding a
> small overhead of a few ms to the container time using libmodsecurity
> shouldn’t cause it to be a bottleneck
>

Yeah, this makes sense :) I don't quite agree with the usage of a WAF in
this context, but I do understand your perspective.


> Do you know if there is any documentation on at the interfaces or should I
> look at the source code?
>

IIRC the "official" API documentation is generated from doxygen. So that,
or again have a look at the example files in the Modsecurity repo, as well
as the nginx and apache connectors.

Re: [mod-security-users] Language Bindings for libmodsecurity/ModSecurity v3

[Robert P. <rpa...@fe...>]

On Thu, Jun 7, 2018 at 3:26 PM, Osama Elnaggar <oel...@gm...>
wrote:

> Thank Robert.  I remember the discussion + the useful benchmarks you and
> others shared
>
> The FaaS model is different from your high performance proxy model as FaaS
> basically runs a single concurrent request per container (with the
> containers scaling to accommodate additional incoming requests) so adding a
> small overhead of a few ms to the container time using libmodsecurity
> shouldn’t cause it to be a bottleneck
>

Yeah, this makes sense :) I don't quite agree with the usage of a WAF in
this context, but I do understand your perspective.


> Do you know if there is any documentation on at the interfaces or should I
> look at the source code?
>

IIRC the "official" API documentation is generated from doxygen. So that,
or again have a look at the example files in the Modsecurity repo, as well
as the nginx and apache connectors.

Re: [mod-security-users] Language Bindings for libmodsecurity/ModSecurity v3

[Osama E. <oel...@gm...>]

Thank Robert.  I remember the discussion + the useful benchmarks you and
others shared

The FaaS model is different from your high performance proxy model as FaaS
basically runs a single concurrent request per container (with the
containers scaling to accommodate additional incoming requests) so adding a
small overhead of a few ms to the container time using libmodsecurity
shouldn’t cause it to be a bottleneck

Do you know if there is any documentation on at the interfaces or should I
look at the source code?

Thanks.

-- 
Osama Elnaggar

On June 8, 2018 at 4:21:29 AM, Robert Paprocki (
rpa...@fe...) wrote:

Hi,

On Wed, Jun 6, 2018 at 9:25 PM, Osama Elnaggar <oel...@gm...>
wrote:

> Hi Robert,
>
> It is interesting that you mentioned performance.  Could you shed more
> light on this?  Is the performance hit significantly more than standard
> ModSecurity?
>

There was some discussion on this list a few months back about
libmodsecurity's performance as it stands today, so I would just point you
there :) Given it's design and throughput capacity, it's not interesting
for me to develop a LuaJIT FFI binding to work within OpenResty or other
high-performance proxies and deploy it in performance-sensitive
environments.

The development of the Modsecurity-nginx connector was another reason I
never really pushed development; there was already a native integration
into Nginx, so no reason to write a Lua module wrapper around this, since
it wouldn't add any useful features.

Re: [mod-security-users] Language Bindings for libmodsecurity/ModSecurity v3

[Robert P. <rpa...@fe...>]

Hi,

On Wed, Jun 6, 2018 at 9:25 PM, Osama Elnaggar <oel...@gm...>
wrote:

> Hi Robert,
>
> It is interesting that you mentioned performance.  Could you shed more
> light on this?  Is the performance hit significantly more than standard
> ModSecurity?
>

There was some discussion on this list a few months back about
libmodsecurity's performance as it stands today, so I would just point you
there :) Given it's design and throughput capacity, it's not interesting
for me to develop a LuaJIT FFI binding to work within OpenResty or other
high-performance proxies and deploy it in performance-sensitive
environments.

The development of the Modsecurity-nginx connector was another reason I
never really pushed development; there was already a native integration
into Nginx, so no reason to write a Lua module wrapper around this, since
it wouldn't add any useful features.

Re: [mod-security-users] Language Bindings for libmodsecurity/ModSecurity v3

[Osama E. <oel...@gm...>]

Hi Robert,

I still haven’t started but i was interested in seeing what others had done
in this area.  My use case was in FaaS (Lambda, Azure Functions, etc.)
architectures / environments where you can’t deploy ModSecurity in-line
(unless you re-architecture everything to through some instances which is
an anti-pattern) and the WAF provided by your cloud provider is very
limited.

It is interesting that you mentioned performance.  Could you shed more
light on this?  Is the performance hit significantly more than standard
ModSecurity?

Thanks.

-- 
Osama Elnaggar

On June 7, 2018 at 8:39:44 AM, Robert Paprocki (
rpa...@fe...) wrote:

Hi,

On Wed, Jun 6, 2018 at 2:28 PM, Chaim Sanders <ch...@ch...>
wrote:

> I think you might be looking for something like this:
>
> https://github.com/SpiderLabs/ModSecurity/tree/v3/master/
> examples/simple_example_using_c
>

I was going to suggest this as well ^

I started writing bindings for both PUC Lua and LuaJIT (ffi), but stopped
for performance reasons

There is also https://github.com/senghoo/modsecurity-go, but it is
abandoned at this point (again for performance reasons).

Overall, for any integration there will be two focal points: gathering HTTP
data to feed into libmodsecurity, and the C/swing/FFI/whatever-have-you
logic to integrate libmodsecurity into the environment in question.

Are there any specific troubles or spots of question you're running into
while building an integration?
------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/