Closed piyushroshan closed 2 years ago
IMHO this would not work.
A rule like the following would require preserving the last chain. So it would be better to preserve the match message and data from the rule/subrule where the msg, logdata action are specified. I have a fix in work that solves this.
SecRule REQUEST_HEADERS "@rx attack" \
"id:20,\
phase:1,\
log,\
chain"
SecRule MATCHED_VARS_NAMES "@rx host" \
msg:'Chained rule test',\
logdata:'Found %{MATCHED_VAR} in %{MATCHED_VAR_NAME}',\
"block"
IMHO this would not work.
A rule like the following would require preserving the last chain. So it would be better to preserve the match message and data from the rule/subrule where the msg, logdata action are specified. I have a fix in work that solves this.
SecRule REQUEST_HEADERS "@rx attack" \ "id:20,\ phase:1,\ log,\ chain" SecRule MATCHED_VARS_NAMES "@rx host" \ msg:'Chained rule test',\ logdata:'Found %{MATCHED_VAR} in %{MATCHED_VAR_NAME}',\ "block"
@piyushroshan If there are more than one chained rules, say 3, each chained rules has its logdata. Then how we will handle this? Or this is not a valid case?
This issue is stale because it has been open for 30 days with no activity.
This was fixed, right @piyushroshan ?
Yes.
Description
The MATCHED_VAR_NAME is taken from the chained rule. It should instead be taken from the rule where msg action is defined.
Variables are expanded incorrectly for Log and Msg of Rule
MATCHED_VAR expands to REQUEST_HEADERS:host i.e key but it should be attack i.e. value of MATCHED_VAR MATCHED_VAR_NAME expands to MATCHED_VARS_NAMES:REQUEST_HEADERS:host i.e. key:value but it should be value of MATCHED_VAR_NAME
It seems the msg, data gets overridden as the chain rule gets evaluated.
Steps to reproduce
Expected result
Actual result