Repository navigation
Conversation
Fixes owasp-modsecurity#2991 Unknown headers were copied into headers_in/headers_out with apr_table_setn(), so each duplicate overwrote the previous entry and only the last value survived. HTTP.SYS already exposes every duplicate as a separate HTTP_UNKNOWN_HEADER entry, so switch both loops to apr_table_addn() to keep all values. This also makes duplicate Set-Cookie values reachable: HTTP.SYS keeps one value in the known header slot and pushes the rest into the unknown header list, where they were previously lost (and also clobbered the known slot value, since known headers are transferred first).
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
Hi @A13501350, thanks for this patch - if I'm right, this fixes a bug. Could you add a test case which shows the issue and the correct behavior? The test could be here, with a new target, for eg. |
|
Happy to add tests. However, |
This branch has not been deployed
2 participants
Fixes #2991
Problem
On IIS, when multiple response headers share the same name (e.g.
Set-Cookie), ModSecurity only records the last one. Consequently, rules using&RESPONSE_HEADERS:/Set-Cookie/(count) orRESPONSE_HEADERS:Set-Cookienever match earlier values, and audit log part F collapses duplicates to a single entry. The same defect exists for request-side unknown headers.Root cause
In
iis/mymodule.cpp, bothOnSendResponseandOnBeginRequestcopy unknown headers into the corresponding APR table withapr_table_setn(), which replaces any existing entry with the same key. HTTP.SYS already exposes every duplicate as a separateHTTP_UNKNOWN_HEADERentry inpUnknownHeaders[], but each loop iteration overwrote the previous one, so only the last value survived.Fix
Switch both unknown-header loops from
apr_table_setn()toapr_table_addn(), preserving all values of identically-named headers. ModSecurity's collection generators already iterate over every table entry, so duplicate headers become fully visible to rules and the audit log.