mod-security-developers Mailing List for ModSecurity
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-developers — Development discussion about mod_security
You can subscribe to this list here.
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(12) |
Mar
(42) |
Apr
(68) |
May
(30) |
Jun
(50) |
Jul
(17) |
Aug
(3) |
Sep
(5) |
Oct
(7) |
Nov
(3) |
Dec
(4) |
| 2012 |
Jan
(11) |
Feb
(11) |
Mar
(37) |
Apr
|
May
(21) |
Jun
(21) |
Jul
(12) |
Aug
(41) |
Sep
(19) |
Oct
(31) |
Nov
(24) |
Dec
(10) |
| 2013 |
Jan
(12) |
Feb
(18) |
Mar
(3) |
Apr
(8) |
May
(35) |
Jun
(5) |
Jul
(38) |
Aug
(5) |
Sep
(2) |
Oct
(4) |
Nov
(11) |
Dec
(6) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(11) |
Apr
(18) |
May
(2) |
Jun
(1) |
Jul
(11) |
Aug
(5) |
Sep
|
Oct
(15) |
Nov
(13) |
Dec
(9) |
| 2015 |
Jan
(2) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(11) |
Oct
(14) |
Nov
(4) |
Dec
(1) |
| 2016 |
Jan
(11) |
Feb
(19) |
Mar
(20) |
Apr
(6) |
May
(3) |
Jun
(17) |
Jul
(5) |
Aug
|
Sep
(7) |
Oct
(2) |
Nov
(2) |
Dec
(12) |
| 2017 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(15) |
| 2018 |
Jan
(13) |
Feb
(2) |
Mar
(14) |
Apr
(9) |
May
|
Jun
(6) |
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(13) |
Dec
(1) |
| 2019 |
Jan
(2) |
Feb
(9) |
Mar
(28) |
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(10) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ervin H. <ai...@gm...> - 2024-07-28 07:47:19
|
Hi Harikisan, Unfortunately there are still few differences between behaviors of mod_security2 and libmodsecurity3. First we try to decrease these differences, then we should try to focus on the performance (of libmodsecurity3 - it's still a bit far behind mod_security2). After we can clarify these things, we can focus on the connector. Feel free to join the project, if you have time/capacity to help. Thanks, a. On Sun, Jul 28, 2024 at 9:14 AM Harikisan Nalawade <har...@gm...> wrote: > Hi All, > > We are using the Apache server in our production environment. To use > ModSecurity V3 (libmodsecurity), we need to use the ModSecurity-apache > connector. This project is under development and not production-ready. The > functionality is not complete, so we cannot use use with Apache HTTP > Server. When can we expect it to be complete? > > > Thanks & Regards, > Harikisan Nalawade > _______________________________________________ > mod-security-developers mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-developers > ModSecurity Services from Trustwave's SpiderLabs: > https://www.trustwave.com/spiderLabs.php |
|
From: Ervin H. <ai...@gm...> - 2024-07-28 07:42:25
|
Hi Harikisan, I can't promise we will release the next version in July, but we will try to finish the work in the next few weeks. Thanks for your patience. a. On Sun, Jul 28, 2024 at 9:13 AM Harikisan Nalawade <har...@gm...> wrote: > Hi All, > > We are using the Apache server in our production environment. We want to > upgrade modsecurity to latest version(old ModSecurity (v2.x.x)) but > ModSecurity (v2.x.x) release the last version (v2.9.7) in Jan 5, 2023 from > then there is not any release for v2.x.x. ModSecurity (V2.9.7) has > vulnerabilities. We want to know When will v2.9.8 be released with security > fixes? > > > Thanks & Regards, > Harikisan Nalawade > _______________________________________________ > mod-security-developers mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-developers > ModSecurity Services from Trustwave's SpiderLabs: > https://www.trustwave.com/spiderLabs.php |
|
From: Harikisan N. <har...@gm...> - 2024-07-28 07:13:18
|
Hi All, We are using the Apache server in our production environment. To use ModSecurity V3 (libmodsecurity), we need to use the ModSecurity-apache connector. This project is under development and not production-ready. The functionality is not complete, so we cannot use use with Apache HTTP Server. When can we expect it to be complete? Thanks & Regards, Harikisan Nalawade |
|
From: Harikisan N. <har...@gm...> - 2024-07-28 07:12:00
|
Hi All, We are using the Apache server in our production environment. We want to upgrade modsecurity to latest version(old ModSecurity (v2.x.x)) but ModSecurity (v2.x.x) release the last version (v2.9.7) in Jan 5, 2023 from then there is not any release for v2.x.x. ModSecurity (V2.9.7) has vulnerabilities. We want to know When will v2.9.8 be released with security fixes? Thanks & Regards, Harikisan Nalawade |
|
From: Ervin H. <ai...@gm...> - 2024-01-11 13:48:12
|
Hi all, perhaps most users read the news: Trustwave transfers ModSecurity custodianship to the OWASP (Open Worldwide Application Security Project). This means the development of ModSecurity (mod_security2 Apache module, libmodsecurit3 library and libnginx-mod-http-modsecurity Nginx module) will continue under the umbrella of OWASP. Here are the announcements: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/trustwave-transfers-modsecurity-custodianship-to-the-open-worldwide-application-security-project/ https://owasp.org/blog/2024/01/09/ModSecurity.html There is a public channel on OWASP's Slack workspace, called #project-modsecurity. You can join the workspace here: https://owasp.org/slack/invite. Feel free to join that channel if you have any questions or ideas. Regards, a. |
|
From: s k. <mrs...@gm...> - 2022-03-04 00:48:38
|
Thanks, Ervin. I'll switch to the mod-security-users list. Best, skwok On Wed, Mar 2, 2022 at 9:54 PM Ervin Hegedüs <ai...@gm...> wrote: > Hi, > > (just my 2 cents: I'm not sure this is the right list for your > question. See available lists: > > https://sourceforge.net/p/mod-security/mailman/ > > I think the best choice is the > > https://sourceforge.net/projects/mod-security/lists/mod-security-users) > > > On Wed, Mar 02, 2022 at 05:22:57PM -0800, s kwok wrote: > > Hi, > > > > I'd like to ask if it is feasible to have modsec enabled for some nginx > > sites and disabled for the rest altogether on the same server. Is it > > recommended in terms of performance and stability? Thanks! > > > yes, see documentation: > > https://github.com/SpiderLabs/ModSecurity-nginx#modsecurity > > modsecurity > > syntax: modsecurity on | off > > context: http, server, location > > default: off > > Turns on or off ModSecurity functionality. Note that this configuration > directive is no longer related to the SecRule state. Instead, it now > serves solely as an nginx flag to enable or disable the module. > > eg: > > server { > listen 80; > listen [::]:80; > > ... > ... > > # Enable ModSecurity WAF, if need > modsecurity on; > > location / { > ... > ... > > > > a. > > > > _______________________________________________ > mod-security-developers mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-developers > ModSecurity Services from Trustwave's SpiderLabs: > https://www.trustwave.com/spiderLabs.php > |
|
From: Ervin H. <ai...@gm...> - 2022-03-03 05:53:58
|
Hi, (just my 2 cents: I'm not sure this is the right list for your question. See available lists: https://sourceforge.net/p/mod-security/mailman/ I think the best choice is the https://sourceforge.net/projects/mod-security/lists/mod-security-users) On Wed, Mar 02, 2022 at 05:22:57PM -0800, s kwok wrote: > Hi, > > I'd like to ask if it is feasible to have modsec enabled for some nginx > sites and disabled for the rest altogether on the same server. Is it > recommended in terms of performance and stability? Thanks! yes, see documentation: https://github.com/SpiderLabs/ModSecurity-nginx#modsecurity modsecurity syntax: modsecurity on | off context: http, server, location default: off Turns on or off ModSecurity functionality. Note that this configuration directive is no longer related to the SecRule state. Instead, it now serves solely as an nginx flag to enable or disable the module. eg: server { listen 80; listen [::]:80; ... ... # Enable ModSecurity WAF, if need modsecurity on; location / { ... ... a. |
|
From: s k. <mrs...@gm...> - 2022-03-03 01:23:16
|
Hi, I'd like to ask if it is feasible to have modsec enabled for some nginx sites and disabled for the rest altogether on the same server. Is it recommended in terms of performance and stability? Thanks! Best, skwok |
|
From: <877...@qq...> - 2022-02-24 05:49:32
|
Christian，
At least the latest mod-security has no this issue.
Best,
huiming
------------------ 原始邮件 ------------------
发件人: "mod-security-developers" <mod...@li...>;
发送时间: 2022年2月23日(星期三) 下午5:26
收件人: "mod-security-developers"<mod...@li...>;"Christian Folini"<chr...@ne...>;
抄送: "huiming"<877...@qq...>;"huiming via mod-security-developers"<mod...@li...>;
主题: [Mod-security-developers] 回复： 回复： 回复： 回复： rule 921170
hi Christian,
the test docker is from coreruleset/tests/docker-compose.yml.
modsec3-nginx:
container_name: modsec3-nginx
image: owasp/modsecurity-crs:nginx
the modsecurity is 3.0.6.
root@2030a8c24f8a:/usr/local/modsecurity/lib# ls
libmodsecurity.so libmodsecurity.so.3 libmodsecurity.so.3.0 libmodsecurity.so.3.0.6
the input "GET /?pineapple=pizza&pineapple2=aint-pizza HTTP/1.1", host: "172.19.0.3" should not generate rule 921180's log.
so this is mod-security bug?
2022/02/23 09:16:24 [info] 26#26: *14 ModSecurity: Warning. Matched "Operator `Rx' with parameter `(?:^([\d.]+|\[[\da-f:]+\]|[\da-f:]+)(:[\d]+)?$)' against variable `REQUEST_HEADERS:Host' (Value: `172.19.0.3' ) [file "/etc/modsecurity.d/owasp-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "743"] [id "920350"] [rev ""] [msg "Host header is a numeric IP address"] [data "172.19.0.3"] [severity "4"] [ver "OWASP_CRS/3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "modsecurity"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [tag "PCI/6.5.10"] [hostname "172.19.0.3"] [uri "/"] [unique_id "1645607784"] [ref "o0,10o0,10v105,10"], client: 172.19.0.1, server: localhost, request: "GET /?pineapple=pizza&pineapple2=aint-pizza HTTP/1.1", host: "172.19.0.3"
2022/02/23 09:16:24 [info] 26#26: *14 ModSecurity: Warning. Matched "Operator `Rx' with parameter `TX:paramcounter_(.*)' against variable `MATCHED_VARS_NAMES:TX:paramcounter_ARGS_NAMES' (Value: `TX:paramcounter_ARGS_NAMES' ) [file "/etc/modsecurity.d/owasp-crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf"] [line "331"] [id "921180"] [rev ""] [msg "HTTP Parameter Pollution (ARGS_NAMES)"] [data "Matched Data: TX:paramcounter_ARGS_NAMES found within MATCHED_VARS_NAMES:TX:paramcounter_ARGS_NAMES: TX:paramcounter_ARGS_NAMES"] [severity "2"] [ver "OWASP_CRS/3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "${MODSEC_TAG}"] [tag "${MODSEC_TAG}"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS"] [tag "capec/1000/152/137/15/460"] [tag "paranoia-level/3"] [hostname "172.19.0.3"] [uri "/"] [unique_id "1645607784"] [ref "o0,26o16,10v139,26"], client: 172.19.0.1, server: localhost, request: "GET /?pineapple=pizza&pineapple2=aint-pizza HTTP/1.1", host: "172.19.0.3"
2022/02/23 09:16:24 [info] 26#26: *14 ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `8' ) [file "/etc/modsecurity.d/owasp-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "139"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 8)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "${MODSEC_TAG}"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "172.19.0.3"] [uri "/"] [unique_id "1645607784"] [ref ""], client: 172.19.0.1, server: localhost, request: "GET /?pineapple=pizza&pineapple2=aint-pizza HTTP/1.1", host: "172.19.0.3"
2022/02/23 09:16:24 [info] 26#26: *14 client 172.19.0.1 closed keepalive connection
------------------ 原始邮件 ------------------
发件人: "mod-security-developers" <mod...@li...>;
发送时间: 2022年2月23日(星期三) 下午4:41
收件人: "Christian Folini"<chr...@ne...>;
抄送: "huiming"<877...@qq...>;"huiming via mod-security-developers"<mod...@li...>;
主题: [Mod-security-developers] 回复： 回复： 回复： rule 921170
OK, let me checkout my platform.
------------------ 原始邮件 ------------------
发件人: "Christian Folini" <chr...@ne...>;
发送时间: 2022年2月23日(星期三) 下午4:38
收件人: "huiming"<877...@qq...>;
抄送: "huiming via mod-security-developers"<mod...@li...>;
主题: Re: 回复：[Mod-security-developers] 回复： rule 921170
On Wed, Feb 23, 2022 at 04:31:15PM +0800, huiming wrote:
> MATCHED_VAR_NAME&nbsp;should be changed to&nbsp;MATCHED_VAR.&nbsp;
No, MATCHED_VAR is the value of the variable, while MATCHED_VAR_NAME is the
key. So MATCHED_VAR is 3 and then 6, while MATCHED_VAR_NAME is ab in both
cases.
> will send a log after a while.
Please do.
Cheers,
Christian
>
>
>
>
>
>
> ------------------&nbsp;原始邮件&nbsp;------------------
> 发件人: "mod-security-developers" <mod...@li...&gt;;
> 发送时间:&nbsp;2022年2月23日(星期三) 下午4:28
> 收件人:&nbsp;"Christian Folini"<chr...@ne...&gt;;"huiming via mod-security-developers"<mod...@li...&gt;;
> 抄送:&nbsp;"huiming"<877...@qq...&gt;;
> 主题:&nbsp;[Mod-security-developers] 回复： rule 921170
>
>
>
> but MATCHED_VAR_NAME is ARGS_NAMES, not ab. so I will not work as expected.
>
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "Christian Folini" <chr...@ne...&gt;;
> 发送时间:&nbsp;2022年2月23日(星期三) 下午4:25
> 收件人:&nbsp;"huiming via mod-security-developers"<mod...@li...&gt;;
> 抄送:&nbsp;"huiming"<877...@qq...&gt;;
> 主题:&nbsp;Re: [Mod-security-developers] rule 921170
>
>
>
> Hey Huiming,
>
> Please be aware this is the ModSecurity mailing list and your question refers
> to the Core Rule Set, which has its own mailing list.
>
> But no problem, I'll respond here.
>
> A request parameter xxx with value yyy is added to two collection in
> ModSecurity.
>
> * ARGS_NAMES will get an item xxx
> * ARGS will get an item yyy
>
> A duplicate parameter means that a given parameter (ab in your baidu example)
> has been submitted multiple times in a request.
>
> So ARGS_NAMES would carry ab twice for the example. Like [ "ab", "ab" ].
>
> Now rule 921170 iterates over ARGS_NAMES and creates a variable
> TX.paramcounter_ab. This is set to 1 for the first occurrence of ab, and then
> to 2 with the 2nd occurrence.
>
> So TX.paramcounter_ab is 2 after 921170.
>
> 921180 will then check whether any of these paramcounters is greater than one.
> The ab paramcounter is, thus the rule 921180 is triggered.
>
> This is a PL3 rule. Thus a very sensitive rule that brings quite a few false
> positives on certain applications. Issuing a parameter multiple times in a
> request is no problem per se and perfectly valid for a web application. But it
> is also a technique of attackers. So if a service makes use of multiple
> submission of the same parameter in a given request, you need to fix the false
> positive with a rule exclusion.
>
> This is a special case since you can not simply remove ab from 921180. Instead
> you need to do the following:
>
> # ModSec Rule Exclusion: 921180 : HTTP Parameter Pollution (ARGS_NAMES:ab)
> SecRuleUpdateTargetById 921180 "!TX:paramcounter_ARGS_NAMES:ab"
>
> Hope this helps!
>
> Christian
>
>
>
>
>
>
> On Wed, Feb 23, 2022 at 04:09:10PM +0800, huiming via mod-security-developers
> wrote:
> &gt; hi,
> &gt;
> &gt;
> &gt; SecRule ARGS_NAMES "@rx ." \ &amp;nbsp; &amp;nbsp; "id:921170,\ &amp;nbsp; &amp;nbsp;
> &gt; phase:2,\ &amp;nbsp; &amp;nbsp; pass,\ &amp;nbsp; &amp;nbsp; nolog,\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'application-multi',\ &amp;nbsp; &amp;nbsp; tag:'language-multi',\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'platform-multi',\ &amp;nbsp; &amp;nbsp; tag:'attack-protocol',\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'paranoia-level/3',\ &amp;nbsp; &amp;nbsp; tag:'OWASP_CRS',\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'capec/1000/152/137/15/460',\ &amp;nbsp; &amp;nbsp; ver:'OWASP_CRS/3.4.0-dev',\
> &gt; &amp;nbsp; &amp;nbsp; setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'"
> &gt;
> &gt;
> &gt;
> &gt; The rule generate only one variable named&amp;nbsp; TX.paramcount_ARGS_NAMES,
> &gt; and assigned the count item in&amp;nbsp; ARGS_NAMES.&amp;nbsp; but this should not
> &gt; be the target I think. because the target is to find duplicate parameters.
> &gt; It should generate a different variable named TX.paramcount_xxx for every
> &gt; variable name,&amp;nbsp; xxx is the variable name.&nbsp; The value is
> &gt; TX.paramcount_xxx is the count of xxx in ARGS_NAMES.&amp;nbsp; &amp;nbsp;same
> &gt; variable name can exist&amp;nbsp; in ARGS_NAMES multiple times. for example
> &gt; http://www.baidu.com?ab=3&amp;amp;ab=6
> &gt;
> &gt;
> &gt; my understanding is wrong?
> &gt;
> &gt;
> &gt; huiming thanks
>
>
> &gt; _______________________________________________
> &gt; mod-security-developers mailing list
> &gt; mod...@li...
> &gt; https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> &gt; ModSecurity Services from Trustwave's SpiderLabs:
> &gt; https://www.trustwave.com/spiderLabs.php |
|
From: <877...@qq...> - 2022-02-23 09:26:51
|
hi Christian,
the test docker is from coreruleset/tests/docker-compose.yml.
modsec3-nginx:
container_name: modsec3-nginx
image: owasp/modsecurity-crs:nginx
the modsecurity is 3.0.6.
root@2030a8c24f8a:/usr/local/modsecurity/lib# ls
libmodsecurity.so libmodsecurity.so.3 libmodsecurity.so.3.0 libmodsecurity.so.3.0.6
the input "GET /?pineapple=pizza&pineapple2=aint-pizza HTTP/1.1", host: "172.19.0.3" should not generate rule 921180's log.
so this is mod-security bug?
2022/02/23 09:16:24 [info] 26#26: *14 ModSecurity: Warning. Matched "Operator `Rx' with parameter `(?:^([\d.]+|\[[\da-f:]+\]|[\da-f:]+)(:[\d]+)?$)' against variable `REQUEST_HEADERS:Host' (Value: `172.19.0.3' ) [file "/etc/modsecurity.d/owasp-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "743"] [id "920350"] [rev ""] [msg "Host header is a numeric IP address"] [data "172.19.0.3"] [severity "4"] [ver "OWASP_CRS/3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "modsecurity"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [tag "PCI/6.5.10"] [hostname "172.19.0.3"] [uri "/"] [unique_id "1645607784"] [ref "o0,10o0,10v105,10"], client: 172.19.0.1, server: localhost, request: "GET /?pineapple=pizza&pineapple2=aint-pizza HTTP/1.1", host: "172.19.0.3"
2022/02/23 09:16:24 [info] 26#26: *14 ModSecurity: Warning. Matched "Operator `Rx' with parameter `TX:paramcounter_(.*)' against variable `MATCHED_VARS_NAMES:TX:paramcounter_ARGS_NAMES' (Value: `TX:paramcounter_ARGS_NAMES' ) [file "/etc/modsecurity.d/owasp-crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf"] [line "331"] [id "921180"] [rev ""] [msg "HTTP Parameter Pollution (ARGS_NAMES)"] [data "Matched Data: TX:paramcounter_ARGS_NAMES found within MATCHED_VARS_NAMES:TX:paramcounter_ARGS_NAMES: TX:paramcounter_ARGS_NAMES"] [severity "2"] [ver "OWASP_CRS/3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "${MODSEC_TAG}"] [tag "${MODSEC_TAG}"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS"] [tag "capec/1000/152/137/15/460"] [tag "paranoia-level/3"] [hostname "172.19.0.3"] [uri "/"] [unique_id "1645607784"] [ref "o0,26o16,10v139,26"], client: 172.19.0.1, server: localhost, request: "GET /?pineapple=pizza&pineapple2=aint-pizza HTTP/1.1", host: "172.19.0.3"
2022/02/23 09:16:24 [info] 26#26: *14 ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `8' ) [file "/etc/modsecurity.d/owasp-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "139"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 8)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "${MODSEC_TAG}"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "172.19.0.3"] [uri "/"] [unique_id "1645607784"] [ref ""], client: 172.19.0.1, server: localhost, request: "GET /?pineapple=pizza&pineapple2=aint-pizza HTTP/1.1", host: "172.19.0.3"
2022/02/23 09:16:24 [info] 26#26: *14 client 172.19.0.1 closed keepalive connection
------------------ 原始邮件 ------------------
发件人: "mod-security-developers" <mod...@li...>;
发送时间: 2022年2月23日(星期三) 下午4:41
收件人: "Christian Folini"<chr...@ne...>;
抄送: "huiming"<877...@qq...>;"huiming via mod-security-developers"<mod...@li...>;
主题: [Mod-security-developers] 回复： 回复： 回复： rule 921170
OK, let me checkout my platform.
------------------ 原始邮件 ------------------
发件人: "Christian Folini" <chr...@ne...>;
发送时间: 2022年2月23日(星期三) 下午4:38
收件人: "huiming"<877...@qq...>;
抄送: "huiming via mod-security-developers"<mod...@li...>;
主题: Re: 回复：[Mod-security-developers] 回复： rule 921170
On Wed, Feb 23, 2022 at 04:31:15PM +0800, huiming wrote:
> MATCHED_VAR_NAME&nbsp;should be changed to&nbsp;MATCHED_VAR.&nbsp;
No, MATCHED_VAR is the value of the variable, while MATCHED_VAR_NAME is the
key. So MATCHED_VAR is 3 and then 6, while MATCHED_VAR_NAME is ab in both
cases.
> will send a log after a while.
Please do.
Cheers,
Christian
>
>
>
>
>
>
> ------------------&nbsp;原始邮件&nbsp;------------------
> 发件人: "mod-security-developers" <mod...@li...&gt;;
> 发送时间:&nbsp;2022年2月23日(星期三) 下午4:28
> 收件人:&nbsp;"Christian Folini"<chr...@ne...&gt;;"huiming via mod-security-developers"<mod...@li...&gt;;
> 抄送:&nbsp;"huiming"<877...@qq...&gt;;
> 主题:&nbsp;[Mod-security-developers] 回复： rule 921170
>
>
>
> but MATCHED_VAR_NAME is ARGS_NAMES, not ab. so I will not work as expected.
>
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "Christian Folini" <chr...@ne...&gt;;
> 发送时间:&nbsp;2022年2月23日(星期三) 下午4:25
> 收件人:&nbsp;"huiming via mod-security-developers"<mod...@li...&gt;;
> 抄送:&nbsp;"huiming"<877...@qq...&gt;;
> 主题:&nbsp;Re: [Mod-security-developers] rule 921170
>
>
>
> Hey Huiming,
>
> Please be aware this is the ModSecurity mailing list and your question refers
> to the Core Rule Set, which has its own mailing list.
>
> But no problem, I'll respond here.
>
> A request parameter xxx with value yyy is added to two collection in
> ModSecurity.
>
> * ARGS_NAMES will get an item xxx
> * ARGS will get an item yyy
>
> A duplicate parameter means that a given parameter (ab in your baidu example)
> has been submitted multiple times in a request.
>
> So ARGS_NAMES would carry ab twice for the example. Like [ "ab", "ab" ].
>
> Now rule 921170 iterates over ARGS_NAMES and creates a variable
> TX.paramcounter_ab. This is set to 1 for the first occurrence of ab, and then
> to 2 with the 2nd occurrence.
>
> So TX.paramcounter_ab is 2 after 921170.
>
> 921180 will then check whether any of these paramcounters is greater than one.
> The ab paramcounter is, thus the rule 921180 is triggered.
>
> This is a PL3 rule. Thus a very sensitive rule that brings quite a few false
> positives on certain applications. Issuing a parameter multiple times in a
> request is no problem per se and perfectly valid for a web application. But it
> is also a technique of attackers. So if a service makes use of multiple
> submission of the same parameter in a given request, you need to fix the false
> positive with a rule exclusion.
>
> This is a special case since you can not simply remove ab from 921180. Instead
> you need to do the following:
>
> # ModSec Rule Exclusion: 921180 : HTTP Parameter Pollution (ARGS_NAMES:ab)
> SecRuleUpdateTargetById 921180 "!TX:paramcounter_ARGS_NAMES:ab"
>
> Hope this helps!
>
> Christian
>
>
>
>
>
>
> On Wed, Feb 23, 2022 at 04:09:10PM +0800, huiming via mod-security-developers
> wrote:
> &gt; hi,
> &gt;
> &gt;
> &gt; SecRule ARGS_NAMES "@rx ." \ &amp;nbsp; &amp;nbsp; "id:921170,\ &amp;nbsp; &amp;nbsp;
> &gt; phase:2,\ &amp;nbsp; &amp;nbsp; pass,\ &amp;nbsp; &amp;nbsp; nolog,\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'application-multi',\ &amp;nbsp; &amp;nbsp; tag:'language-multi',\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'platform-multi',\ &amp;nbsp; &amp;nbsp; tag:'attack-protocol',\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'paranoia-level/3',\ &amp;nbsp; &amp;nbsp; tag:'OWASP_CRS',\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'capec/1000/152/137/15/460',\ &amp;nbsp; &amp;nbsp; ver:'OWASP_CRS/3.4.0-dev',\
> &gt; &amp;nbsp; &amp;nbsp; setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'"
> &gt;
> &gt;
> &gt;
> &gt; The rule generate only one variable named&amp;nbsp; TX.paramcount_ARGS_NAMES,
> &gt; and assigned the count item in&amp;nbsp; ARGS_NAMES.&amp;nbsp; but this should not
> &gt; be the target I think. because the target is to find duplicate parameters.
> &gt; It should generate a different variable named TX.paramcount_xxx for every
> &gt; variable name,&amp;nbsp; xxx is the variable name.&nbsp; The value is
> &gt; TX.paramcount_xxx is the count of xxx in ARGS_NAMES.&amp;nbsp; &amp;nbsp;same
> &gt; variable name can exist&amp;nbsp; in ARGS_NAMES multiple times. for example
> &gt; http://www.baidu.com?ab=3&amp;amp;ab=6
> &gt;
> &gt;
> &gt; my understanding is wrong?
> &gt;
> &gt;
> &gt; huiming thanks
>
>
> &gt; _______________________________________________
> &gt; mod-security-developers mailing list
> &gt; mod...@li...
> &gt; https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> &gt; ModSecurity Services from Trustwave's SpiderLabs:
> &gt; https://www.trustwave.com/spiderLabs.php |
|
From: <877...@qq...> - 2022-02-23 08:45:28
|
OK, let me checkout my platform.
------------------ 原始邮件 ------------------
发件人: "Christian Folini" <chr...@ne...>;
发送时间: 2022年2月23日(星期三) 下午4:38
收件人: "huiming"<877...@qq...>;
抄送: "huiming via mod-security-developers"<mod...@li...>;
主题: Re: 回复：[Mod-security-developers] 回复： rule 921170
On Wed, Feb 23, 2022 at 04:31:15PM +0800, huiming wrote:
> MATCHED_VAR_NAME&nbsp;should be changed to&nbsp;MATCHED_VAR.&nbsp;
No, MATCHED_VAR is the value of the variable, while MATCHED_VAR_NAME is the
key. So MATCHED_VAR is 3 and then 6, while MATCHED_VAR_NAME is ab in both
cases.
> will send a log after a while.
Please do.
Cheers,
Christian
>
>
>
>
>
>
> ------------------&nbsp;原始邮件&nbsp;------------------
> 发件人: "mod-security-developers" <mod...@li...&gt;;
> 发送时间:&nbsp;2022年2月23日(星期三) 下午4:28
> 收件人:&nbsp;"Christian Folini"<chr...@ne...&gt;;"huiming via mod-security-developers"<mod...@li...&gt;;
> 抄送:&nbsp;"huiming"<877...@qq...&gt;;
> 主题:&nbsp;[Mod-security-developers] 回复： rule 921170
>
>
>
> but MATCHED_VAR_NAME is ARGS_NAMES, not ab. so I will not work as expected.
>
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "Christian Folini" <chr...@ne...&gt;;
> 发送时间:&nbsp;2022年2月23日(星期三) 下午4:25
> 收件人:&nbsp;"huiming via mod-security-developers"<mod...@li...&gt;;
> 抄送:&nbsp;"huiming"<877...@qq...&gt;;
> 主题:&nbsp;Re: [Mod-security-developers] rule 921170
>
>
>
> Hey Huiming,
>
> Please be aware this is the ModSecurity mailing list and your question refers
> to the Core Rule Set, which has its own mailing list.
>
> But no problem, I'll respond here.
>
> A request parameter xxx with value yyy is added to two collection in
> ModSecurity.
>
> * ARGS_NAMES will get an item xxx
> * ARGS will get an item yyy
>
> A duplicate parameter means that a given parameter (ab in your baidu example)
> has been submitted multiple times in a request.
>
> So ARGS_NAMES would carry ab twice for the example. Like [ "ab", "ab" ].
>
> Now rule 921170 iterates over ARGS_NAMES and creates a variable
> TX.paramcounter_ab. This is set to 1 for the first occurrence of ab, and then
> to 2 with the 2nd occurrence.
>
> So TX.paramcounter_ab is 2 after 921170.
>
> 921180 will then check whether any of these paramcounters is greater than one.
> The ab paramcounter is, thus the rule 921180 is triggered.
>
> This is a PL3 rule. Thus a very sensitive rule that brings quite a few false
> positives on certain applications. Issuing a parameter multiple times in a
> request is no problem per se and perfectly valid for a web application. But it
> is also a technique of attackers. So if a service makes use of multiple
> submission of the same parameter in a given request, you need to fix the false
> positive with a rule exclusion.
>
> This is a special case since you can not simply remove ab from 921180. Instead
> you need to do the following:
>
> # ModSec Rule Exclusion: 921180 : HTTP Parameter Pollution (ARGS_NAMES:ab)
> SecRuleUpdateTargetById 921180 "!TX:paramcounter_ARGS_NAMES:ab"
>
> Hope this helps!
>
> Christian
>
>
>
>
>
>
> On Wed, Feb 23, 2022 at 04:09:10PM +0800, huiming via mod-security-developers
> wrote:
> &gt; hi,
> &gt;
> &gt;
> &gt; SecRule ARGS_NAMES "@rx ." \ &amp;nbsp; &amp;nbsp; "id:921170,\ &amp;nbsp; &amp;nbsp;
> &gt; phase:2,\ &amp;nbsp; &amp;nbsp; pass,\ &amp;nbsp; &amp;nbsp; nolog,\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'application-multi',\ &amp;nbsp; &amp;nbsp; tag:'language-multi',\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'platform-multi',\ &amp;nbsp; &amp;nbsp; tag:'attack-protocol',\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'paranoia-level/3',\ &amp;nbsp; &amp;nbsp; tag:'OWASP_CRS',\ &amp;nbsp; &amp;nbsp;
> &gt; tag:'capec/1000/152/137/15/460',\ &amp;nbsp; &amp;nbsp; ver:'OWASP_CRS/3.4.0-dev',\
> &gt; &amp;nbsp; &amp;nbsp; setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'"
> &gt;
> &gt;
> &gt;
> &gt; The rule generate only one variable named&amp;nbsp; TX.paramcount_ARGS_NAMES,
> &gt; and assigned the count item in&amp;nbsp; ARGS_NAMES.&amp;nbsp; but this should not
> &gt; be the target I think. because the target is to find duplicate parameters.
> &gt; It should generate a different variable named TX.paramcount_xxx for every
> &gt; variable name,&amp;nbsp; xxx is the variable name.&nbsp; The value is
> &gt; TX.paramcount_xxx is the count of xxx in ARGS_NAMES.&amp;nbsp; &amp;nbsp;same
> &gt; variable name can exist&amp;nbsp; in ARGS_NAMES multiple times. for example
> &gt; http://www.baidu.com?ab=3&amp;amp;ab=6
> &gt;
> &gt;
> &gt; my understanding is wrong?
> &gt;
> &gt;
> &gt; huiming thanks
>
>
> &gt; _______________________________________________
> &gt; mod-security-developers mailing list
> &gt; mod...@li...
> &gt; https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> &gt; ModSecurity Services from Trustwave's SpiderLabs:
> &gt; https://www.trustwave.com/spiderLabs.php |
|
From: Christian F. <chr...@ne...> - 2022-02-23 08:38:38
|
On Wed, Feb 23, 2022 at 04:31:15PM +0800, huiming wrote:
> MATCHED_VAR_NAME should be changed to MATCHED_VAR.
No, MATCHED_VAR is the value of the variable, while MATCHED_VAR_NAME is the
key. So MATCHED_VAR is 3 and then 6, while MATCHED_VAR_NAME is ab in both
cases.
> will send a log after a while.
Please do.
Cheers,
Christian
>
>
>
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "mod-security-developers" <mod...@li...>;
> 发送时间: 2022年2月23日(星期三) 下午4:28
> 收件人: "Christian Folini"<chr...@ne...>;"huiming via mod-security-developers"<mod...@li...>;
> 抄送: "huiming"<877...@qq...>;
> 主题: [Mod-security-developers] 回复： rule 921170
>
>
>
> but MATCHED_VAR_NAME is ARGS_NAMES, not ab. so I will not work as expected.
>
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "Christian Folini" <chr...@ne...>;
> 发送时间: 2022年2月23日(星期三) 下午4:25
> 收件人: "huiming via mod-security-developers"<mod...@li...>;
> 抄送: "huiming"<877...@qq...>;
> 主题: Re: [Mod-security-developers] rule 921170
>
>
>
> Hey Huiming,
>
> Please be aware this is the ModSecurity mailing list and your question refers
> to the Core Rule Set, which has its own mailing list.
>
> But no problem, I'll respond here.
>
> A request parameter xxx with value yyy is added to two collection in
> ModSecurity.
>
> * ARGS_NAMES will get an item xxx
> * ARGS will get an item yyy
>
> A duplicate parameter means that a given parameter (ab in your baidu example)
> has been submitted multiple times in a request.
>
> So ARGS_NAMES would carry ab twice for the example. Like [ "ab", "ab" ].
>
> Now rule 921170 iterates over ARGS_NAMES and creates a variable
> TX.paramcounter_ab. This is set to 1 for the first occurrence of ab, and then
> to 2 with the 2nd occurrence.
>
> So TX.paramcounter_ab is 2 after 921170.
>
> 921180 will then check whether any of these paramcounters is greater than one.
> The ab paramcounter is, thus the rule 921180 is triggered.
>
> This is a PL3 rule. Thus a very sensitive rule that brings quite a few false
> positives on certain applications. Issuing a parameter multiple times in a
> request is no problem per se and perfectly valid for a web application. But it
> is also a technique of attackers. So if a service makes use of multiple
> submission of the same parameter in a given request, you need to fix the false
> positive with a rule exclusion.
>
> This is a special case since you can not simply remove ab from 921180. Instead
> you need to do the following:
>
> # ModSec Rule Exclusion: 921180 : HTTP Parameter Pollution (ARGS_NAMES:ab)
> SecRuleUpdateTargetById 921180 "!TX:paramcounter_ARGS_NAMES:ab"
>
> Hope this helps!
>
> Christian
>
>
>
>
>
>
> On Wed, Feb 23, 2022 at 04:09:10PM +0800, huiming via mod-security-developers
> wrote:
> > hi,
> >
> >
> > SecRule ARGS_NAMES "@rx ." \ &nbsp; &nbsp; "id:921170,\ &nbsp; &nbsp;
> > phase:2,\ &nbsp; &nbsp; pass,\ &nbsp; &nbsp; nolog,\ &nbsp; &nbsp;
> > tag:'application-multi',\ &nbsp; &nbsp; tag:'language-multi',\ &nbsp; &nbsp;
> > tag:'platform-multi',\ &nbsp; &nbsp; tag:'attack-protocol',\ &nbsp; &nbsp;
> > tag:'paranoia-level/3',\ &nbsp; &nbsp; tag:'OWASP_CRS',\ &nbsp; &nbsp;
> > tag:'capec/1000/152/137/15/460',\ &nbsp; &nbsp; ver:'OWASP_CRS/3.4.0-dev',\
> > &nbsp; &nbsp; setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'"
> >
> >
> >
> > The rule generate only one variable named&nbsp; TX.paramcount_ARGS_NAMES,
> > and assigned the count item in&nbsp; ARGS_NAMES.&nbsp; but this should not
> > be the target I think. because the target is to find duplicate parameters.
> > It should generate a different variable named TX.paramcount_xxx for every
> > variable name,&nbsp; xxx is the variable name. The value is
> > TX.paramcount_xxx is the count of xxx in ARGS_NAMES.&nbsp; &nbsp;same
> > variable name can exist&nbsp; in ARGS_NAMES multiple times. for example
> > http://www.baidu.com?ab=3&amp;ab=6
> >
> >
> > my understanding is wrong?
> >
> >
> > huiming thanks
>
>
> > _______________________________________________
> > mod-security-developers mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> > ModSecurity Services from Trustwave's SpiderLabs:
> > https://www.trustwave.com/spiderLabs.php
|
|
From: <877...@qq...> - 2022-02-23 08:37:33
|
wget http://www.test00002.com/?aaaaa=3\&baaaa=2\&baaaa=88 [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [9] Target value: "aaaaa" (Variable: ARGS_NAMES) [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [9] Matched vars updated. [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [4] Running [independent] (non-disruptive) action: setvar [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [8] Saving variable: TX:paramcounter_ARGS_NAMES with value: 1 [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [9] Target value: "baaaa" (Variable: ARGS_NAMES) [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [9] Matched vars updated. [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [4] Running [independent] (non-disruptive) action: setvar [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [8] Saving variable: TX:paramcounter_ARGS_NAMES with value: 2 [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [9] Target value: "baaaa" (Variable: ARGS_NAMES) [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [9] Matched vars updated. [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [4] Running [independent] (non-disruptive) action: setvar [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [8] Saving variable: TX:paramcounter_ARGS_NAMES with value: 3 [1645605255] [/?aaaaa=3&baaaa=2&baaaa=88] [4] Rule returned 1. ------------------ 原始邮件 ------------------ 发件人: "huiming" <877...@qq...>; 发送时间: 2022年2月23日(星期三) 下午4:31 收件人: "Christian Folini"<chr...@ne...>;"huiming via mod-security-developers"<mod...@li...>; 主题: 回复：[Mod-security-developers] 回复： rule 921170 MATCHED_VAR_NAME should be changed to MATCHED_VAR. will send a log after a while. ------------------ 原始邮件 ------------------ 发件人: "mod-security-developers" <mod...@li...>; 发送时间: 2022年2月23日(星期三) 下午4:28 收件人: "Christian Folini"<chr...@ne...>;"huiming via mod-security-developers"<mod...@li...>; 抄送: "huiming"<877...@qq...>; 主题: [Mod-security-developers] 回复： rule 921170 but MATCHED_VAR_NAME is ARGS_NAMES, not ab. so I will not work as expected. ------------------ 原始邮件 ------------------ 发件人: "Christian Folini" <chr...@ne...>; 发送时间: 2022年2月23日(星期三) 下午4:25 收件人: "huiming via mod-security-developers"<mod...@li...>; 抄送: "huiming"<877...@qq...>; 主题: Re: [Mod-security-developers] rule 921170 Hey Huiming, Please be aware this is the ModSecurity mailing list and your question refers to the Core Rule Set, which has its own mailing list. But no problem, I'll respond here. A request parameter xxx with value yyy is added to two collection in ModSecurity. * ARGS_NAMES will get an item xxx * ARGS will get an item yyy A duplicate parameter means that a given parameter (ab in your baidu example) has been submitted multiple times in a request. So ARGS_NAMES would carry ab twice for the example. Like [ "ab", "ab" ]. Now rule 921170 iterates over ARGS_NAMES and creates a variable TX.paramcounter_ab. This is set to 1 for the first occurrence of ab, and then to 2 with the 2nd occurrence. So TX.paramcounter_ab is 2 after 921170. 921180 will then check whether any of these paramcounters is greater than one. The ab paramcounter is, thus the rule 921180 is triggered. This is a PL3 rule. Thus a very sensitive rule that brings quite a few false positives on certain applications. Issuing a parameter multiple times in a request is no problem per se and perfectly valid for a web application. But it is also a technique of attackers. So if a service makes use of multiple submission of the same parameter in a given request, you need to fix the false positive with a rule exclusion. This is a special case since you can not simply remove ab from 921180. Instead you need to do the following: # ModSec Rule Exclusion: 921180 : HTTP Parameter Pollution (ARGS_NAMES:ab) SecRuleUpdateTargetById 921180 "!TX:paramcounter_ARGS_NAMES:ab" Hope this helps! Christian On Wed, Feb 23, 2022 at 04:09:10PM +0800, huiming via mod-security-developers wrote: > hi, > > > SecRule ARGS_NAMES "@rx ." \ &nbsp; &nbsp; "id:921170,\ &nbsp; &nbsp; > phase:2,\ &nbsp; &nbsp; pass,\ &nbsp; &nbsp; nolog,\ &nbsp; &nbsp; > tag:'application-multi',\ &nbsp; &nbsp; tag:'language-multi',\ &nbsp; &nbsp; > tag:'platform-multi',\ &nbsp; &nbsp; tag:'attack-protocol',\ &nbsp; &nbsp; > tag:'paranoia-level/3',\ &nbsp; &nbsp; tag:'OWASP_CRS',\ &nbsp; &nbsp; > tag:'capec/1000/152/137/15/460',\ &nbsp; &nbsp; ver:'OWASP_CRS/3.4.0-dev',\ > &nbsp; &nbsp; setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'" > > > > The rule generate only one variable named&nbsp; TX.paramcount_ARGS_NAMES, > and assigned the count item in&nbsp; ARGS_NAMES.&nbsp; but this should not > be the target I think. because the target is to find duplicate parameters. > It should generate a different variable named TX.paramcount_xxx for every > variable name,&nbsp; xxx is the variable name. The value is > TX.paramcount_xxx is the count of xxx in ARGS_NAMES.&nbsp; &nbsp;same > variable name can exist&nbsp; in ARGS_NAMES multiple times. for example > http://www.baidu.com?ab=3&amp;ab=6 > > > my understanding is wrong? > > > huiming thanks > _______________________________________________ > mod-security-developers mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-developers > ModSecurity Services from Trustwave's SpiderLabs: > https://www.trustwave.com/spiderLabs.php |
|
From: Christian F. <chr...@ne...> - 2022-02-23 08:37:32
|
On Wed, Feb 23, 2022 at 04:28:37PM +0800, huiming via mod-security-developers wrote:
> but MATCHED_VAR_NAME is ARGS_NAMES, not ab. so I will not work as expected.
Hmm. It's supposed to be ARGS_NAMES:ab.
What is your platform?
It works fine on my Apache / ModSec 2.9 and I am not aware of issues on
different platforms.
$ curl "http://localhost/?ab=3&ab=6"
-> [2022-02-23 09:35:17.466868] [-:error] 127.0.0.1:52484
YhXxxRDDjxbxdo51x3q-xAAAAAI [client 127.0.0.1] ModSecurity: Warning. Pattern
match "TX:paramcounter_(.*)" at TX:paramcounter_ARGS_NAMES:ab. [file
"/home/dune73/data/git/crs-official/rules/REQUEST-921-PROTOCOL-ATTACK.conf"]
[line "346"] [id "921180"] [msg "HTTP Parameter Pollution (ARGS_NAMES:ab)"]
[data "Matched Data: TX:paramcounter_ARGS_NAMES:ab found within
TX:paramcounter_ARGS_NAMES:ab: TX:paramcounter_ARGS_NAMES:ab"] [severity
"CRITICAL"] [ver "OWASP_CRS/3.4.0-dev"] [tag "application-multi"] [tag
"language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag
"OWASP_CRS"] [tag "capec/1000/152/137/15/460"] [tag "paranoia-level/3"]
[hostname "localhost"] [uri "/"] [unique_id "YhXxxRDDjxbxdo51x3q-xAAAAAI"]
Best,
Christian
>
>
>
>
> ------------------ 原始邮件 ------------------ 发件人:
> "Christian Folini"
> <chr...@ne...>; 发送时间: 2022年2月23日(星期三)
> 下午4:25 收件人: "huiming via
> mod-security-developers"<mod...@li...>;
> 抄送: "huiming"<877...@qq...>; 主题: Re:
> [Mod-security-developers] rule 921170
>
>
>
> Hey Huiming,
>
> Please be aware this is the ModSecurity mailing list and your question
> refers to the Core Rule Set, which has its own mailing list.
>
> But no problem, I'll respond here.
>
> A request parameter xxx with value yyy is added to two collection in
> ModSecurity.
>
> * ARGS_NAMES will get an item xxx * ARGS will get an item yyy
>
> A duplicate parameter means that a given parameter (ab in your baidu
> example) has been submitted multiple times in a request.
>
> So ARGS_NAMES would carry ab twice for the example. Like [ "ab", "ab" ].
>
> Now rule 921170 iterates over ARGS_NAMES and creates a variable
> TX.paramcounter_ab. This is set to 1 for the first occurrence of ab, and
> then to 2 with the 2nd occurrence.
>
> So TX.paramcounter_ab is 2 after 921170.
>
> 921180 will then check whether any of these paramcounters is greater than
> one. The ab paramcounter is, thus the rule 921180 is triggered.
>
> This is a PL3 rule. Thus a very sensitive rule that brings quite a few false
> positives on certain applications. Issuing a parameter multiple times in a
> request is no problem per se and perfectly valid for a web application. But
> it is also a technique of attackers. So if a service makes use of multiple
> submission of the same parameter in a given request, you need to fix the
> false positive with a rule exclusion.
>
> This is a special case since you can not simply remove ab from 921180.
> Instead you need to do the following:
>
> # ModSec Rule Exclusion: 921180 : HTTP Parameter Pollution (ARGS_NAMES:ab)
> SecRuleUpdateTargetById 921180 "!TX:paramcounter_ARGS_NAMES:ab"
>
> Hope this helps!
>
> Christian
>
>
>
>
>
>
> On Wed, Feb 23, 2022 at 04:09:10PM +0800, huiming via
> mod-security-developers wrote: > hi, > > > SecRule ARGS_NAMES
> "@rx ." \ &nbsp; &nbsp; "id:921170,\ &nbsp; &nbsp; >
> phase:2,\ &nbsp; &nbsp; pass,\ &nbsp; &nbsp; nolog,\
> &nbsp; &nbsp; > tag:'application-multi',\ &nbsp; &nbsp;
> tag:'language-multi',\ &nbsp; &nbsp; > tag:'platform-multi',\
> &nbsp; &nbsp; tag:'attack-protocol',\ &nbsp; &nbsp; >
> tag:'paranoia-level/3',\ &nbsp; &nbsp; tag:'OWASP_CRS',\ &nbsp;
> &nbsp; > tag:'capec/1000/152/137/15/460',\ &nbsp; &nbsp;
> ver:'OWASP_CRS/3.4.0-dev',\ > &nbsp; &nbsp;
> setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'" > > > > The
> rule generate only one variable named&nbsp; TX.paramcount_ARGS_NAMES,
> > and assigned the count item in&nbsp; ARGS_NAMES.&nbsp; but this
> should not > be the target I think. because the target is to find
> duplicate parameters. > It should generate a different variable named
> TX.paramcount_xxx for every > variable name,&nbsp; xxx is the
> variable name. The value is > TX.paramcount_xxx is the count of xxx
> in ARGS_NAMES.&nbsp; &nbsp;same > variable name can
> exist&nbsp; in ARGS_NAMES multiple times. for example >
> http://www.baidu.com?ab=3&amp;ab=6 > > > my understanding is
> wrong? > > > huiming thanks
>
>
> > _______________________________________________ >
> mod-security-developers mailing list >
> mod...@li... >
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers >
> ModSecurity Services from Trustwave's SpiderLabs: >
> https://www.trustwave.com/spiderLabs.php
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
|
|
From: <877...@qq...> - 2022-02-23 08:31:32
|
MATCHED_VAR_NAME should be changed to MATCHED_VAR.
will send a log after a while.
------------------ 原始邮件 ------------------
发件人: "mod-security-developers" <mod...@li...>;
发送时间: 2022年2月23日(星期三) 下午4:28
收件人: "Christian Folini"<chr...@ne...>;"huiming via mod-security-developers"<mod...@li...>;
抄送: "huiming"<877...@qq...>;
主题: [Mod-security-developers] 回复： rule 921170
but MATCHED_VAR_NAME is ARGS_NAMES, not ab. so I will not work as expected.
------------------ 原始邮件 ------------------
发件人: "Christian Folini" <chr...@ne...>;
发送时间: 2022年2月23日(星期三) 下午4:25
收件人: "huiming via mod-security-developers"<mod...@li...>;
抄送: "huiming"<877...@qq...>;
主题: Re: [Mod-security-developers] rule 921170
Hey Huiming,
Please be aware this is the ModSecurity mailing list and your question refers
to the Core Rule Set, which has its own mailing list.
But no problem, I'll respond here.
A request parameter xxx with value yyy is added to two collection in
ModSecurity.
* ARGS_NAMES will get an item xxx
* ARGS will get an item yyy
A duplicate parameter means that a given parameter (ab in your baidu example)
has been submitted multiple times in a request.
So ARGS_NAMES would carry ab twice for the example. Like [ "ab", "ab" ].
Now rule 921170 iterates over ARGS_NAMES and creates a variable
TX.paramcounter_ab. This is set to 1 for the first occurrence of ab, and then
to 2 with the 2nd occurrence.
So TX.paramcounter_ab is 2 after 921170.
921180 will then check whether any of these paramcounters is greater than one.
The ab paramcounter is, thus the rule 921180 is triggered.
This is a PL3 rule. Thus a very sensitive rule that brings quite a few false
positives on certain applications. Issuing a parameter multiple times in a
request is no problem per se and perfectly valid for a web application. But it
is also a technique of attackers. So if a service makes use of multiple
submission of the same parameter in a given request, you need to fix the false
positive with a rule exclusion.
This is a special case since you can not simply remove ab from 921180. Instead
you need to do the following:
# ModSec Rule Exclusion: 921180 : HTTP Parameter Pollution (ARGS_NAMES:ab)
SecRuleUpdateTargetById 921180 "!TX:paramcounter_ARGS_NAMES:ab"
Hope this helps!
Christian
On Wed, Feb 23, 2022 at 04:09:10PM +0800, huiming via mod-security-developers
wrote:
> hi,
>
>
> SecRule ARGS_NAMES "@rx ." \ &nbsp; &nbsp; "id:921170,\ &nbsp; &nbsp;
> phase:2,\ &nbsp; &nbsp; pass,\ &nbsp; &nbsp; nolog,\ &nbsp; &nbsp;
> tag:'application-multi',\ &nbsp; &nbsp; tag:'language-multi',\ &nbsp; &nbsp;
> tag:'platform-multi',\ &nbsp; &nbsp; tag:'attack-protocol',\ &nbsp; &nbsp;
> tag:'paranoia-level/3',\ &nbsp; &nbsp; tag:'OWASP_CRS',\ &nbsp; &nbsp;
> tag:'capec/1000/152/137/15/460',\ &nbsp; &nbsp; ver:'OWASP_CRS/3.4.0-dev',\
> &nbsp; &nbsp; setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'"
>
>
>
> The rule generate only one variable named&nbsp; TX.paramcount_ARGS_NAMES,
> and assigned the count item in&nbsp; ARGS_NAMES.&nbsp; but this should not
> be the target I think. because the target is to find duplicate parameters.
> It should generate a different variable named TX.paramcount_xxx for every
> variable name,&nbsp; xxx is the variable name. The value is
> TX.paramcount_xxx is the count of xxx in ARGS_NAMES.&nbsp; &nbsp;same
> variable name can exist&nbsp; in ARGS_NAMES multiple times. for example
> http://www.baidu.com?ab=3&amp;ab=6
>
>
> my understanding is wrong?
>
>
> huiming thanks
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php |
|
From: <877...@qq...> - 2022-02-23 08:28:51
|
but MATCHED_VAR_NAME is ARGS_NAMES, not ab. so I will not work as expected.
------------------ 原始邮件 ------------------
发件人: "Christian Folini" <chr...@ne...>;
发送时间: 2022年2月23日(星期三) 下午4:25
收件人: "huiming via mod-security-developers"<mod...@li...>;
抄送: "huiming"<877...@qq...>;
主题: Re: [Mod-security-developers] rule 921170
Hey Huiming,
Please be aware this is the ModSecurity mailing list and your question refers
to the Core Rule Set, which has its own mailing list.
But no problem, I'll respond here.
A request parameter xxx with value yyy is added to two collection in
ModSecurity.
* ARGS_NAMES will get an item xxx
* ARGS will get an item yyy
A duplicate parameter means that a given parameter (ab in your baidu example)
has been submitted multiple times in a request.
So ARGS_NAMES would carry ab twice for the example. Like [ "ab", "ab" ].
Now rule 921170 iterates over ARGS_NAMES and creates a variable
TX.paramcounter_ab. This is set to 1 for the first occurrence of ab, and then
to 2 with the 2nd occurrence.
So TX.paramcounter_ab is 2 after 921170.
921180 will then check whether any of these paramcounters is greater than one.
The ab paramcounter is, thus the rule 921180 is triggered.
This is a PL3 rule. Thus a very sensitive rule that brings quite a few false
positives on certain applications. Issuing a parameter multiple times in a
request is no problem per se and perfectly valid for a web application. But it
is also a technique of attackers. So if a service makes use of multiple
submission of the same parameter in a given request, you need to fix the false
positive with a rule exclusion.
This is a special case since you can not simply remove ab from 921180. Instead
you need to do the following:
# ModSec Rule Exclusion: 921180 : HTTP Parameter Pollution (ARGS_NAMES:ab)
SecRuleUpdateTargetById 921180 "!TX:paramcounter_ARGS_NAMES:ab"
Hope this helps!
Christian
On Wed, Feb 23, 2022 at 04:09:10PM +0800, huiming via mod-security-developers
wrote:
> hi,
>
>
> SecRule ARGS_NAMES "@rx ." \ &nbsp; &nbsp; "id:921170,\ &nbsp; &nbsp;
> phase:2,\ &nbsp; &nbsp; pass,\ &nbsp; &nbsp; nolog,\ &nbsp; &nbsp;
> tag:'application-multi',\ &nbsp; &nbsp; tag:'language-multi',\ &nbsp; &nbsp;
> tag:'platform-multi',\ &nbsp; &nbsp; tag:'attack-protocol',\ &nbsp; &nbsp;
> tag:'paranoia-level/3',\ &nbsp; &nbsp; tag:'OWASP_CRS',\ &nbsp; &nbsp;
> tag:'capec/1000/152/137/15/460',\ &nbsp; &nbsp; ver:'OWASP_CRS/3.4.0-dev',\
> &nbsp; &nbsp; setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'"
>
>
>
> The rule generate only one variable named&nbsp; TX.paramcount_ARGS_NAMES,
> and assigned the count item in&nbsp; ARGS_NAMES.&nbsp; but this should not
> be the target I think. because the target is to find duplicate parameters.
> It should generate a different variable named TX.paramcount_xxx for every
> variable name,&nbsp; xxx is the variable name. The value is
> TX.paramcount_xxx is the count of xxx in ARGS_NAMES.&nbsp; &nbsp;same
> variable name can exist&nbsp; in ARGS_NAMES multiple times. for example
> http://www.baidu.com?ab=3&amp;ab=6
>
>
> my understanding is wrong?
>
>
> huiming thanks
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php |
|
From: Christian F. <chr...@ne...> - 2022-02-23 08:25:14
|
Hey Huiming,
Please be aware this is the ModSecurity mailing list and your question refers
to the Core Rule Set, which has its own mailing list.
But no problem, I'll respond here.
A request parameter xxx with value yyy is added to two collection in
ModSecurity.
* ARGS_NAMES will get an item xxx
* ARGS will get an item yyy
A duplicate parameter means that a given parameter (ab in your baidu example)
has been submitted multiple times in a request.
So ARGS_NAMES would carry ab twice for the example. Like [ "ab", "ab" ].
Now rule 921170 iterates over ARGS_NAMES and creates a variable
TX.paramcounter_ab. This is set to 1 for the first occurrence of ab, and then
to 2 with the 2nd occurrence.
So TX.paramcounter_ab is 2 after 921170.
921180 will then check whether any of these paramcounters is greater than one.
The ab paramcounter is, thus the rule 921180 is triggered.
This is a PL3 rule. Thus a very sensitive rule that brings quite a few false
positives on certain applications. Issuing a parameter multiple times in a
request is no problem per se and perfectly valid for a web application. But it
is also a technique of attackers. So if a service makes use of multiple
submission of the same parameter in a given request, you need to fix the false
positive with a rule exclusion.
This is a special case since you can not simply remove ab from 921180. Instead
you need to do the following:
# ModSec Rule Exclusion: 921180 : HTTP Parameter Pollution (ARGS_NAMES:ab)
SecRuleUpdateTargetById 921180 "!TX:paramcounter_ARGS_NAMES:ab"
Hope this helps!
Christian
On Wed, Feb 23, 2022 at 04:09:10PM +0800, huiming via mod-security-developers
wrote:
> hi,
>
>
> SecRule ARGS_NAMES "@rx ." \ "id:921170,\
> phase:2,\ pass,\ nolog,\
> tag:'application-multi',\ tag:'language-multi',\
> tag:'platform-multi',\ tag:'attack-protocol',\
> tag:'paranoia-level/3',\ tag:'OWASP_CRS',\
> tag:'capec/1000/152/137/15/460',\ ver:'OWASP_CRS/3.4.0-dev',\
> setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'"
>
>
>
> The rule generate only one variable named TX.paramcount_ARGS_NAMES,
> and assigned the count item in ARGS_NAMES. but this should not
> be the target I think. because the target is to find duplicate parameters.
> It should generate a different variable named TX.paramcount_xxx for every
> variable name, xxx is the variable name. The value is
> TX.paramcount_xxx is the count of xxx in ARGS_NAMES. same
> variable name can exist in ARGS_NAMES multiple times. for example
> http://www.baidu.com?ab=3&ab=6
>
>
> my understanding is wrong?
>
>
> huiming thanks
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
|
|
From: <877...@qq...> - 2022-02-23 08:09:31
|
hi,
SecRule ARGS_NAMES "@rx ." \
"id:921170,\
phase:2,\
pass,\
nolog,\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-protocol',\
tag:'paranoia-level/3',\
tag:'OWASP_CRS',\
tag:'capec/1000/152/137/15/460',\
ver:'OWASP_CRS/3.4.0-dev',\
setvar:'TX.paramcounter_%{MATCHED_VAR_NAME}=+1'"
The rule generate only one variable named TX.paramcount_ARGS_NAMES, and assigned the count item in ARGS_NAMES.
but this should not be the target I think. because the target is to find duplicate parameters.
It should generate a different variable named TX.paramcount_xxx for every variable name, xxx is the variable name.
The value is TX.paramcount_xxx is the count of xxx in ARGS_NAMES. same variable name can exist in ARGS_NAMES multiple times. for example http://www.baidu.com?ab=3&ab=6
my understanding is wrong?
huiming
thanks |
|
From: Ervin H. <ai...@gm...> - 2021-09-29 07:31:31
|
On Wed, Sep 29, 2021 at 03:18:21PM +0800, huiming wrote: > so I will impact all expirevar rule ? > sorry, I don't understand this... a. |
|
From: <877...@qq...> - 2021-09-29 07:18:43
|
so I will impact all expirevar rule ?
------------------ 原始邮件 ------------------
发件人: "Ervin Hegedüs" <ai...@gm...>;
发送时间: 2021年9月29日(星期三) 下午2:44
收件人: "huiming via mod-security-developers"<mod...@li...>;
抄送: "huiming"<877...@qq...>;
主题: Re: [Mod-security-developers] seems expirevar not supported.
Hi,
On Wed, Sep 29, 2021 at 01:30:44PM +0800, huiming via mod-security-developers wrote:
> all,&nbsp;
>
> seems expoirevar not supported.
> | ACTION_EXPIRE_VAR
> &nbsp; &nbsp; &nbsp; &nbsp;{
> &nbsp; &nbsp; &nbsp; &nbsp; //ACTION_NOT_SUPPORTED("ExpireVar", @0);
> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ACTION_CONTAINER($$, new actions::Action($1));&nbsp; //it is Action, not expirevar; Morever NO expirevar implementation.
> &nbsp; &nbsp; &nbsp; &nbsp;}
yes, there are few issues about this:
https://github.com/SpiderLabs/ModSecurity/issues/1803
https://github.com/SpiderLabs/ModSecurity/issues/2556
> I did not make test, but from code, it seems that expirevar not supported. Anyone can help me understand this.
what's the question?
a.
|
|
From: Ervin H. <ai...@gm...> - 2021-09-29 06:44:54
|
Hi,
On Wed, Sep 29, 2021 at 01:30:44PM +0800, huiming via mod-security-developers wrote:
> all,
>
> seems expoirevar not supported.
> | ACTION_EXPIRE_VAR
> {
> //ACTION_NOT_SUPPORTED("ExpireVar", @0);
> ACTION_CONTAINER($$, new actions::Action($1)); //it is Action, not expirevar; Morever NO expirevar implementation.
> }
yes, there are few issues about this:
https://github.com/SpiderLabs/ModSecurity/issues/1803
https://github.com/SpiderLabs/ModSecurity/issues/2556
> I did not make test, but from code, it seems that expirevar not supported. Anyone can help me understand this.
what's the question?
a.
|
|
From: <877...@qq...> - 2021-09-29 05:31:08
|
all,
seems expoirevar not supported.
| ACTION_EXPIRE_VAR
{
//ACTION_NOT_SUPPORTED("ExpireVar", @0);
ACTION_CONTAINER($$, new actions::Action($1)); //it is Action, not expirevar; Morever NO expirevar implementation.
}
I did not make test, but from code, it seems that expirevar not supported. Anyone can help me understand this.
thanks
huiming |
|
From: Matteo P. S. <mat...@st...> - 2021-07-22 17:25:56
|
Hi all, I'm working on porting libModsecurity to WASM, the main project is to use it inside a service mesh as an Istio extension. The problem arises because the final makefile generated by the whole build process includes header files gcc-specific, and not the ones for clang (on which Emscripten is based). Does anyone ever encounter a similar problem? Is there a way to customize the building process to make it compatible with Emscripten? For further details and the whole error: https://github.com/SpiderLabs/ModSecurity/issues/2590 A similar issue with the same error is: https://github.com/emscripten-core/emscripten/issues/9067 Thanks for any help, Matteo Pace |
|
From: adoring g. <gad...@gm...> - 2021-07-08 22:20:26
|
Hi, I am observing a memory leak with the operator objects not being freed, once the ruleset is cleaned up. With a test program that initializes modsecurity, reads a ruleset and cleans up the ruleset global_modsec = msc_init(); global_rules = msc_create_rules_set(); const char* error = NULL; msc_rules_add_file(global_rules, "rules.conf", &error); msc_rules_cleanup(global_rules); msc_cleanup(global_modsec); I see memory leaks: ==1836== *==1836== 142,421,048 bytes in 30,350 blocks are possibly lost in loss record 410 of 412* ==1836== at 0x4C2C089: calloc (vg_replace_malloc.c:762) ==1836== by 0x4FBAFDD: acmp_add_pattern (acmp.cc:517) ==1836== by 0x4FA4CBB: modsecurity::operators::Pm::init(std::string const&, std::string*) (pm.cc:136) ==1836== by 0x4EFF823: yy::seclang_parser::parse() (seclang-parser.yy:874) ==1836== by 0x4F39373: modsecurity::Parser::Driver::parse(std::string const&, std::string const&) (driver.cc:145) ==1836== by 0x4F39697: modsecurity::Parser::Driver::parseFile(std::string const&) (driver.cc:189) ==1836== by 0x4F50CC6: modsecurity::RulesSet::loadFromUri(char const*) (rules_set.cc:53) ==1836== by 0x4F52542: msc_rules_add_file (rules_set.cc:296) ==1836== by 0x4011D7: process_rules (modsec_memory.c:15) ==1836== by 0x40126C: main (modsec_memory.c:33) ==1836== ==1836== *569,323,113 (1,344 direct, 569,321,769 indirect) bytes in 21 blocks are definitely lost in loss record 412 of 412* ==1836== at 0x4C2A593: operator new(unsigned long) (vg_replace_malloc.c:344) ==1836== by 0x4EF56B1: yy::seclang_parser::parse() (seclang-parser.yy:1032) ==1836== by 0x4F39373: modsecurity::Parser::Driver::parse(std::string const&, std::string const&) (driver.cc:145) ==1836== by 0x4F39697: modsecurity::Parser::Driver::parseFile(std::string const&) (driver.cc:189) ==1836== by 0x4F50CC6: modsecurity::RulesSet::loadFromUri(char const*) (rules_set.cc:53) ==1836== by 0x4F52542: msc_rules_add_file (rules_set.cc:296) ==1836== by 0x4011D7: process_rules (modsec_memory.c:15) ==1836== by 0x40126C: main (modsec_memory.c:33) How do we deallocate the memory used by the parser? |
|
From: Felipe Z. <fe...@zi...> - 2021-07-07 23:07:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It is a pleasure to announce the release of ModSecurity version 3.0.5 (libModSecurity). This version contains several improvements in different areas, including new features, cleanups, overall performance improvements, and fixes. A remarkable feature for version 3.0.5 is the limitation on the number of arguments to process; this is especially useful while inspecting JSON with a high number of key/values. Read more - https://github.com/SpiderLabs/ModSecurity/pull/2234 New features - - Having ARGS_NAMES, variables proxied [@zimmerle, @martinhsv, @KaNikita] - - Use explicit path for cross-compile environments. [Issue #2485 - @dtoubelis] - - Fix: FILES variable does not use multipart part name for key [Issue #2377 - @martinhsv] - - Regression: Mark the test as failed in case of segfault. [@zimmerle] - - GeoIP: switch to GEOIP_MEMORY_CACHE from GEOIP_INDEX_CACHE [Issues #2378, #2186 - @defanator] - - Add support to test framework for audit log content verification and add regression tests for issues #2000, #2196 [@zimmerle] - - Support configurable limit on number of arguments processed [Issue #2234 - @jleproust, @martinhsv] - - Multipart Content-Dispostion should allow field: filename*= [@martinhsv] - - Adds support to lua 5.4 [@zimmerle] - - Add support for new operator rxGlobal [@martinhsv] Bug fixes - - Replaces put with setenv in SetEnv action [Issue #2469 - @martinhsv, @WGH-, @zimmerle] - - Regex key selection should not be case-sensitive [Issue #2296, #2107, #2297 - @michaelgranzow-avi, @victorhora, @airween, @martinhsv, @zimmerle] - - Fix: Only delete Multipart tmp files after rules have run [Issue #2427 - @martinhsv] - - Fixed MatchedVar on chained rules [Issue #2423, #2435, #2436 - @michaelgranzow-avi] - - Fix maxminddb link on FreeBSD [Issue #2131 - @granalberto, @zimmerle] - - Fix IP address logging in Section A [Issue #2300 - @inaratech, @zavazingo, @martinhsv] - - rx: exit after full match (remove /g emulation); ensure capture groups occuring after unused groups still populate TX vars [Issue #2336 - @martinhsv] - - Correct CHANGES file entry for #2234 - - Fix rule-update-target for non-regex [Issue #2251 - @martinhsv] - - Fix configure script when packaging for Buildroot [Issue #2235 - @frankvanbever] - - modsecurity.pc.in: add Libs.private [Issue #1918, #2253 - @ffontaine, @Dridi, @victorhora] Security impacting issues - - Handle URI received with uri-fragment [@martinhsv] The complete list of changes is available on our changelogs: - - https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.5 The source and binaries (and the respective hashes/signatures) are available at: - - https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.5 The list of open issues is available on GitHub: - - https://github.com/SpiderLabs/ModSecurity/labels/3.x Stay tuned. We are going to release a follow-up blog post detailing the significant bits of this release. Thanks to everybody who helped in this process: reporting issues, making comments and suggestions, sending patches, and participating in the community ;) -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iF0EARECAB0WIQQZDvrMoen6RmqOzZzm37CM6LESdwUCYOYt2wAKCRDm37CM6LES d1tmAJ9fc8jBWOPX+76nGAm4fTl/2ZQVHACcCbJNBofbrmXU6Glc1CyZkBjE8wg= =OIWQ -----END PGP SIGNATURE----- |
10 messages has been excluded from this view by a project administrator.
