Thread: [Mod-security-developers] rule 921170
Brought to you by:
victorhora,
zimmerletw
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: 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: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: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: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: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: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: <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-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 |