Re: [mod-security-users] @pmFromFile for blocked vars

[Reindl H. <h.r...@th...>]

that way it works - unsure of the performance impact while i am not a
fan of chaining rules at all for that reason

SecRule ARGS (.*)
"id:'89',phase:2,chain,logdata:'%{matched_var}',block,msg:'blocked
variable'"
SecRule MATCHED_VARS_NAMES "@pmFromFile 99_blocked_vars.data"
"chain,capture"
SecRule MATCHED_VAR "@streq ARGS:%{tx.0}"

"ARGS_NAMES @pmf 99_blocked" as far as i remember matches also parts and
instead exactly "base_dir" every param which contains it

Am 17.02.20 um 19:38 schrieb Christian Folini:
> Hallo Harald,
> 
> I think the problem with your rule is order of execution of chained rules.
> 
> In your first example, the 1st SecRule is executed for base_dir and then
> for x. VAR is now x. Then the 2nd rule is executed for var = x, which
> does not bring a hit.
> 
> This is counterintuitive of course, but when you think about how things are
> probably handled internally, then it makes sense. At least some sense. But
> I wish it was different.
> 
> Is there a reason you do not do ARGS_NAMES @pmf 99_blocked... ?
> I did not think this through, tough.
> 
> Building on your hack, you could do setvar:tx.var_%{MATCHED_VAR_NAME}
> and then TX:/^var_/ "@pmf ...
> 
> Just my 2 cents,
> 
> Christian
> 
> 
> On Mon, Feb 17, 2020 at 07:08:57PM +0100, Reindl Harald wrote:
>> Hi
>>
>> the rule below needs some love
>>
>> no hit: ?base_dir=x&x=1
>> hit: ?base_dir=x
>>
>> why in the world does that only hit if the url ends with a listed param
>> and is the some nicer way for "exact macth" than the ***var*** hack?
>>
>> --------------------------------
>>
>> SecRule ARGS_NAMES ^(.*)$
>> "id:'89',chain,setvar:tx.var='***%{matched_var}***',msg:'blocked
>> variable: %{matched_var}'"
>> SecRule TX:VAR "@pmFromFile 99_blocked_vars.data"
>>
>> --------------------------------
>>
>> 99_blocked_vars.data:
>>
>> ***base_dir***