Matched \"Operator `Eq' with parameter `0' against variable `REQUEST_HEADERS:Host' (Value: `0' )

[MorrowxD]

ModSecurity does not recognize the Host header when using HTTP/3. I believe I have the correct versions of ModSecurity, the connector, and the rules. Is any custom configuration necessary to handle HTTP/3 requests?

{
  "transaction": {
    "client_ip": "XXXXXX",
    "time_stamp": "Wed Dec 18 15:52:34 2024",
    "server_id": "a53237e5ec8faf273b2ea40bcca024979fdaed7f",
    "client_port": 46779,
    "host_ip": "XXXXXX",
    "host_port": 443,
    "unique_id": "173453355437.118418",
    "request": {
      "method": "GET",
      "http_version": 3,
      "uri": "/",
      "headers": {
        "sec-fetch-user": "?1",
        "sec-ch-ua": "\"Chromium\";v=\"129\", \"Not=A?Brand\";v=\"8\"",
        "sec-fetch-dest": "document",
        "sec-fetch-mode": "navigate",
        "user-agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36",
        "sec-fetch-site": "cross-site",
        "sec-ch-ua-platform": "\"Linux\"",
        "upgrade-insecure-requests": "1",
        "sec-ch-ua-mobile": "?0",
        "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
        "cache-control": "max-age=0",
        "accept-encoding": "gzip, deflate, br, zstd",
        "accept-language": "en-US,en;q=0.9",
        "priority": "u=0, i"
      }
    },
    "response": {
      "body": "",
      "http_code": 200,
      "headers": {
        "Server": "nginx/1.26.2",
        "Date": "Wed, 18 Dec 2024 14:52:34 GMT",
        "Content-Type": "application/octet-stream",
        "Connection": "keep-alive",
        "Alt-Svc": "h3=\":443\"; ma=86400"
      }
    },
    "producer": {
      "modsecurity": "ModSecurity v3.0.13 (Linux)",
      "connector": "ModSecurity-nginx v1.0.3",
      "secrules_engine": "DetectionOnly",
      "components": [
        "OWASP_CRS/4.9.0\""
      ]
    },
    "messages": [
      {
        "message": "Request Missing a Host Header",
        "details": {
          "match": "Matched \"Operator `Eq' with parameter `0' against variable `REQUEST_HEADERS:Host' (Value: `0' )",
          "reference": "",
          "ruleId": "920280",
          "file": "/usr/local/nginx/conf/crs4/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
          "lineNumber": "574",
          "data": "",
          "severity": "4",
          "ver": "OWASP_CRS/4.9.0",
          "rev": "",
          "tags": [
            "application-multi",
            "language-multi",
            "platform-multi",
            "attack-protocol",
            "paranoia-level/1",
            "OWASP_CRS",
            "capec/1000/210/272",
            "PCI/6.5.10"
          ],
          "maturity": "0",
          "accuracy": "0"
        }
      }
    ]
  }
}

[airween]

Hi @MorrowxD,

Is any custom configuration necessary to handle HTTP/3 requests?

No, there is no any custom configuration which needs to handle HTTP/3. And libmodsecurity3 logs all headers that it gets in the request.

What I can assume is that HTTP/3 is not necessary to have host header, and you faced off with that scenario.

[MorrowxD]

How can I prevent the logs from growing excessively? Should this rule be disabled for HTTP/3?

[airween]

@MorrowxD,

I think this is more a Coreruleset issue than ModSecurity.

Anyway, it's interesting why do you have an audit log entry with response code 200? ModSecurity's default config file contains SecAuditLogRelevantStatus with value "^(?:5|4(?!04))", this means audit.log entry is generated only when the status code is 5XX or 4XX except 404.

For the solution: you can create an exclusion against that rule. For more information, please take a look at this page. A quick explanation:

SecRule REQUEST_PROTOCOL "^HTTP/3(\.0)$" \
    "id:10000,\
    phase:1,\
    pass,\
    t:none,\
    ctl:ruleRemoveById=920280"

This will prevent to execute rule 920280 if the protocol is HTTP/3 or HTTP/3.0.

[airween]

@MorrowxD any news around here? Can we close this issue?

[off-circuit]

@airween Just a quick update, because I just stumbled onto this with the same issue: Your exclusion role fixes the warning, thanks. The root problem remains, though. But as you pointed out, this is rather a CRS problem.

[AnnoyingTechnology]

Has anyone found a way to retrieve the domain name in ModSec when using HTTP/3 ?
The Host is not relevant in HTTP/3 context, and therefore missing.

• SERVER_NAME is empty
• REQUEST_HEADER:Host is empty
• REQUEST_HEADER:authority is empty
• Using nginx's properly populated $host to populate a custom input header via the headers-more-nginx-module doesn't work : ModSec doesn't see it
• Using nginx's properly populated $host to populate a custom input header via the libnginx-mod-http-lua module doesn't work : ModSec doesn't see it

I'm in a situation where many of my exclusions are domain-based (+ URL + ARGS) in a wildcard vhost (so single modsec exclusion file).
Pretty much stuck without a way to retrieve the domain name.

This doesn't 100% belong to this issue, so I can open a distinct Issue if needed.

[airween]

@AnnoyingTechnology,

there is a pending PR for #ModSecurity-nginx/332, perhaps that solves this issue. I'm waiting for the developer's response there.

[AnnoyingTechnology]

Thanks.
From a preliminary reading of the diff, I don't see how that could solve the issue.

Currently the only hack capable of forwarding the domain name of an HTTP/3 request, is injecting the host in ModSec's transaction ID using nginx's modsecurity_transaction_id "$host|$request_id"; followed by SecRule UNIQUE_ID "@rx ^([^|]+)\|" "id:10000,phase:1,pass,nolog,capture,t:lowercase,setvar:tx.HOSTNAME=%{TX.1}" and matching on TX:HOSTNAME for followup rules.

[airween]

Ah, sorry, I think now I see the problem. Probably we should add this feature into ModSecurity-nginx connector - eg. I can imagine a directive where the admin can describe what Nginx variable should the connector pass to the engine.

[AnnoyingTechnology]

That would be appreciable, but I think the default behavior also needs to change somehow.

Consider the following, when logging an HTTP/[1-2] request, modsec_audit logs

---ou9JNira---B--
GET /shady-url HTTP/2.0
host: domain.tld
[...not relevant...]

Which gives the host and allows for debugging and whitelisting.
Using HTTP/3 we don't even have a single mention of the host/domain in the logs !

So it's basically impossible to deploy modsec if your starting point is a functionnal HTTP/3 setup. The initial whitelisting step is not possible.

Always passing and logging Nginx's $host would seem like a sane default as it is properly and safely populated by Nginx regardless of the http version.

[airween]

I've reviewed the RFC and please correct it, I'm afraid if a (HTTP/2 or HTTP/3) request does not include either the Host or :authority headers, it is an invalid request.

See:

7.2. Host and :authority

The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names.
In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in some cases, supplanted by the ":authority" pseudo-header field of a request's control data.

  Host = uri-host [ ":" port ] ; Section 4

The target URI's authority information is critical for handling a request. A user agent MUST generate a Host header field in a request unless it sends that information as an ":authority" pseudo-header field. A user agent that sends Host SHOULD send it as the first field in the header section of a request.

May be Nginx (or the connector) does not add pseudo headers to the REQUEST_HEADERS collection. But after a quick check, it seems like Nginx adds :authority header as host, see here, and the connector uses this information. But this header does not appear in REQUEST_HEADERS, I added that in #ModSecurity-nginx/353 as the correct transaction's host value (relevant fix in the library is #2906).

But yes, we have to fix this - I mean it would be nice to add pseudo headers to REQUEST_HEADERS collection.

[airween]

I made a small research, and I still can't try HTTP/3, but if I send a HTTP/2 request to my server, where there is no Host header, only :authority pseudo header, then it appears in ModSecurity under the REQUEST_HEADERS as Host key.

I think this means Nginx adds :authority as Host, the connector does not need to handle that.

Could you try these steps and share the result?

• add this rule to your rule set, if it possible before all other rules:

SecRule REQUEST_HEADERS "@unconditionalMatch" \
    "id:999111,\
    phase:1,\
    pass,\
    t:none,\
    logdata:'%{MATCHED_VARS_NAMES} - %{MATCHED_VARS}'"

• turn on your debug.log:

SecDebugLog /var/log/nginx/modsec_debug.log   # or any path that you can use
SecDebugLogLevel 9

• send a HTTP/3 request
• check debug.log especially the rule 999111

Here is what I got:

[175587451226.367895] [/?q=/bin/bash] [4] (Rule: 999111) Executing operator "UnconditionalMatch against REQUEST_HEADERS.
[175587451226.367895] [/?q=/bin/bash] [9] Target value: "mytest.host.name" (Variable: REQUEST_HEADERS:host)
[175587451226.367895] [/?q=/bin/bash] [9] Matched vars updated.
[175587451226.367895] [/?q=/bin/bash] [9] Target value: "custom_h2_client" (Variable: REQUEST_HEADERS:user-agent)
[175587451226.367895] [/?q=/bin/bash] [9] Matched vars updated.
[175587451226.367895] [/?q=/bin/bash] [9] Target value: "*/*" (Variable: REQUEST_HEADERS:accept)
[175587451226.367895] [/?q=/bin/bash] [9] Matched vars updated.
[175587451226.367895] [/?q=/bin/bash] [4] Rule returned 1.

I think this provides that the connector adds Host header.

Please try to reproduce this and share your results.

[AnnoyingTechnology]

Will try next week.

But pretty sure this doesn't happen on my versions, as I've had many clients connecting in HTTP/3 and no REQUEST_HEADER:Host being ever populated on ModSec. If this was the case I wouldn't have had to find such a workaround.

• nginx version: nginx/1.26.3
• libnginx-mod-http-modsecurity/stable,now 1.0.3-2+b2
• libmodsecurity3t64/stable,now 3.0.14-1

[airween]

Meanwhile I was able to check HTTP/3 with Nginx, and... well, I have to tell you you're right.

Look at my results:
HTTP/2

curl --http2 https://my.test.site

error.log:

*1 ModSecurity: Warning. Matched "Operator `UnconditionalMatch' with parameter `'... request: "GET / HTTP/2.0", host: ...

debug.log:

[175597358885.446458] [/] [4] (Rule: 999111) Executing operator "UnconditionalMatch against REQUEST_HEADERS.
[175597358885.446458] [/] [9] Target value: "my.test.site" (Variable: REQUEST_HEADERS:host)
[175597358885.446458] [/] [9] Matched vars updated.
[175597358885.446458] [/] [9] Target value: "curl/8.14.1" (Variable: REQUEST_HEADERS:user-agent)
[175597358885.446458] [/] [9] Matched vars updated.
[175597358885.446458] [/] [9] Target value: "*/*" (Variable: REQUEST_HEADERS:accept)
[175597358885.446458] [/] [9] Matched vars updated.
[175597358885.446458] [/] [4] Rule returned 1.

HTTP/3

curl --http3 https://my.test.site

error.log

*5 ModSecurity: Warning. Matched "Operator `UnconditionalMatch' with parameter `'... request: "GET / HTTP/3.0"

Please note, that there is no host field at the end of line!

[175597366320.323733] [/] [4] (Rule: 999111) Executing operator "UnconditionalMatch against REQUEST_HEADERS.
[175597366320.323733] [/] [9] Target value: "curl/8.14.1" (Variable: REQUEST_HEADERS:user-agent)
[175597366320.323733] [/] [9] Matched vars updated.
[175597366320.323733] [/] [9] Target value: "*/*" (Variable: REQUEST_HEADERS:accept)
[175597366320.323733] [/] [9] Matched vars updated.
[175597366320.323733] [/] [4] Rule returned 1.

I'm afraid this is the Nginx's http3 module's problem. The connector is the same, the engine is the same... But I try to continue the investigation.