libModSecurity3: `REQUEST_HEADERS` names are treated as case sensitive

[EsadCetiner]

Describe the bug

libModSecurity3 treats REQUEST_HEADERS names as case sensitive when they are supposed to be treaten as case insensitive. This is not the case for ModSecurity2.

Logs and dumps

N/A

To Reproduce

Create the following rules, the first is meant to simulate a rule exclusion and the second a blocking rule:

SecRule REQUEST_FILENAME "@unconditionalMatch" \
    "id:1,\
    phase:1,\
    pass,\
    t:none,\
    ctl:ruleRemoveTargetById=2;REQUEST_HEADERS:referer"

SecRule REQUEST_HEADERS:Referer "@contains <evil-string>" \
    "id:2,\
    phase:1,\
    deny,\
    t:none,\
    log"

Then run this curl command, you'll be blocked by the WAF when you should've be allowed:
curl -H "Referer: <evil-string>" localhost

If I match the exact case in my rule exclusion then the request is allowed as expected:

SecRule REQUEST_FILENAME "@unconditionalMatch" \
    "id:1,\
    phase:1,\
    pass,\
    t:none,\
    ctl:ruleRemoveTargetById=2;REQUEST_HEADERS:Referer"

SecRule REQUEST_HEADERS:Referer "@contains <evil-string>" \
    "id:2,\
    phase:1,\
    deny,\
    t:none,\
    log"

Expected behavior

Request header names should be treated as case insensitive, just like ModSecurity2.

Server (please complete the following information):

• OS: Ubuntu 24.04
• ModSecurity Version: 3.0.14
• NGINX Connector Version: v1.0.4
• NGINX Version: 1.24.0

Rule Set (please complete the following information):

• N/A

Additional context

N/A

[airween]

Hi @EsadCetiner,

thanks for reporting this.

I think this happens in case of exclusion handling, I mean if the admin adds an exclusion with ctl:ruleRemoveTargetById action, then the target will be case sensitive.

I think the behavior is correct if we add a rule like this:

SecRule REQUEST_HEADERS:FakeHeader "@rx bash" \
    "id:999112,\
    phase:1,\
    deny,\
    t:none,\
    logdata:'%{MATCHED_VARS_NAMES} - %{MATCHED_VARS}'"

and send a request like this:

curl -v -H "fakeheader: /bin/bash" http://localhost

In this case I got this result:

[175777764613.010976] [/] [4] (Rule: 999112) Executing operator "Rx" with param "bash" against REQUEST_HEADERS:FakeHeader.
[175777764613.010976] [/] [9] Target value: "/bin/bash" (Variable: REQUEST_HEADERS:fakeheader)
[175777764613.010976] [/] [9] Matched vars updated.

But indeed the explained behavior is wrong.

Thanks again, I'll check this soon.

[airween]

@EsadCetiner could you take a look at the new regression tests under #3442? See the commit.

Also if it's possible, could you try the patch too?

[EsadCetiner]

@airween Thanks for the quick fix, I just tested it locally and I can confirm the issue is fixed.

[airween]

Closing as completed via #3442.