mod-security-developers Mailing List for ModSecurity
Brought to you by:
victorhora,
zimmerletw
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
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
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----- |
From: Felipe Z. <fe...@zi...> - 2021-06-21 23:07:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, It is a pleasure to announce ModSecurity version 2.9.4. Release 2.9.4 contains fixes and enhancements atop version 2.9.3. The details on this release are available on GitHub: - https://github.com/SpiderLabs/ModSecurity/releases/tag/v2.9.4 Further details on ModSecurity v2 can be found on the project README: - https://github.com/SpiderLabs/ModSecurity/tree/v2/master The list of open issues is available on GitHub: - https://github.com/SpiderLabs/ModSecurity/labels/2.x IMPORTANT: - - Windows installer no longer includes OWASP CRS. - - Release files are no longer available on modsecurity.org, only on GitHub. - - ModSecurity version 2 will be available and maintained parallel to version 3. There is no ETA to deprecate version 2.x. ModSecurity versions 2 and 3 have a completely independent development/release cycle. -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iFwEARECAB0WIQQZDvrMoen6RmqOzZzm37CM6LESdwUCYNEVfgAKCRDm37CM6LES dxUkAJ4naJ9ysl5HZPSEhmO0wxrLduDI4wCYzRhp8EuuSp/TW5uVNdF+eDl8UA== =yA1i -----END PGP SIGNATURE----- |
From: Felipe Z. <fe...@zi...> - 2021-06-21 23:03:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, It is a pleasure to announce ModSecurity version 2.9.4. Release 2.9.4 contains fixes and enhancements atop version 2.9.3. The details on this release are available on GitHub: - https://github.com/SpiderLabs/ModSecurity/releases/tag/v2.9.4 Further details on ModSecurity v2 can be found on the project README: - https://github.com/SpiderLabs/ModSecurity/tree/v2/master The list of open issues is available on GitHub: - https://github.com/SpiderLabs/ModSecurity/labels/2.x IMPORTANT: - - Windows installer no longer includes OWASP CRS. - - Release files are no longer available on modsecurity.org, only on GitHub. - - ModSecurity version 2 will be available and maintained parallel to version 3. There is no ETA to deprecate version 2.x. ModSecurity versions 2 and 3 have a completely independent development/release cycle. -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iFwEARECAB0WIQQZDvrMoen6RmqOzZzm37CM6LESdwUCYNEVfgAKCRDm37CM6LES dxUkAJ4naJ9ysl5HZPSEhmO0wxrLduDI4wCYzRhp8EuuSp/TW5uVNdF+eDl8UA== =yA1i -----END PGP SIGNATURE----- |
From: Christian F. <chr...@ne...> - 2020-09-14 09:52:48
|
Dear all, ModSecurity v3.0.x is affected by a Denial of Service vulnerability due to the global matching of regular expressions. The combination of a non-anchored regular expression and the ModSecurity “capture” action can be exploited via a specially crafted payload. While ModSecurity v2.x used to quit the execution of a regular expression after the first match. ModSecurity v3.0.x silently changed the behavior to global matching. This results in a DoS for existing non-anchored regexes in rules containing the “capture” action. It also fills the TX variable space beyond the documented limit of 10 instances. The defense is handicapped due to the absence of the SecRequestBodyNoFilesLimit directive. The vendor Trustwave Spiderlabs dropped this functionality for ModSecurity v3. The vendor did not publish a new release, but there is a patch that brings back the former behavior. CVSSv3: 7.5 HIGH https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&version=3.1 Exploitability Metrics: * Attack Vector: Network * Attack Complexity: Low * Priviledges Required: None * User Interaction: None * Scope: Unchanged Impact Metrics: * Confidentiality Impact: None * Integrity Impact: None * Availability Impact: High Weakness Enumeration: CWE-400: Uncontrolled Resource Consumption Known Affected Software Configurations: ModSecurity v3.0.0 ModSecurity v3.0.1 ModSecurity v3.0.2 ModSecurity v3.0.3 ModSecurity v3.0.4 (patch for this version available) More Information and patch: https://coreruleset.org/20200914/cve-2020-15598/ Best regards, Christian Folini and Ervin Hegedüs on behalf of the CRS team -- OWASP ModSecurity Core Rule Set - https://coreruleset.org |
From: Felipe Z. <fe...@zi...> - 2020-01-13 18:19:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi It is a pleasure to announce the release of ModSecurity version 3.0.4 (libModSecurity). This version contains a number of improvements in different areas. These include cleanups, better practices for improved code readability, resilience and overall performance and security fixes. A huge refactoring was placed on the Regex engine, which is now more performant. The Logging was polished and hex-encoded strings are now pretty printed. An operator to detect Australian social security number was added. The audit log is now working with section H and better dealing with logs, nologs and auditlogs combinations. POTENTIAL SECURITY ISSUES: - - Cookie parser problems [@theMiddleBlue, @airween, @martinhsv] The list with the full changes can be found on the project CHANGES file, available here: - - https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.4/CHANGES The list of open issues is available on GitHub: - - https://github.com/SpiderLabs/ModSecurity/labels/3.x As with every new release, a milestone was created to host all the issues that will be fixed till we reach the given milestone. With that, we not only give the community the full transparency of the work that is being doing on ModSec, but also even more chances to participate. Milestones give the chance to anyone from the community to deduce when and what will be released. Thanks to everybody who helped in this process: reporting issues, making comments and suggestions, sending patches and so on. Further details on the compilation process for ModSecurity v3, can be found on the project README: - https://github.com/SpiderLabs/ModSecurity/tree/v3/master#compilation Complementary documentation for the connectors are available here: - nginx: https://github.com/SpiderLabs/ModSecurity-nginx/#compilation - Apache: https://github.com/SpiderLabs/ModSecurity-apache/#compilation IMPORTANT: ModSecurity version 2 will be available and maintained parallel to version 3. There is no ETA to deprecate the version 2.x. New features and major improvements will be implemented on version 3.x. Security or major bugs are planned to be back ported. Version 2 and version 3 has a completely independent development/release cycle. Br., Felipe "Zimmerle" Costa -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iF0EARECAB0WIQQZDvrMoen6RmqOzZzm37CM6LESdwUCXhxx8QAKCRDm37CM6LES dy8jAJ4l6Goa0qn+RyxwrFPa8Zjl9t8HagCeJeHULU8EsT2M2S0Ho6ROgOdQstM= =GeNp -----END PGP SIGNATURE----- |