Multipart: data after the final boundary in a later chunk sets MULTIPART_DATA_BEFORE instead of MULTIPART_DATA_AFTER
I maintainer di solito rispondono entro 1 giorno
@airween ci sta già lavorando.
Dal 15/10/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
what
Both multipart parsers handle "data after the last boundary" in two places, and the two places set different flags.
When the epilogue data arrives in the same chunk as the closing delimiter, the parser sets the after flag:
- v2:
apache2/msc_multipart.cline 1382 (msr->mpd->flag_data_after = 1;) - v3:
src/request_body_processor/multipart.ccline 1830 (m_flag_data_after = 1;)
When the epilogue data arrives in a later chunk, the early return at the top of the chunk processor sets the before flag instead:
- v2:
apache2/msc_multipart.cline 1158 (msr->mpd->flag_data_before = 1;, debug message "Ignoring data after last boundary") - v3:
src/request_body_processor/multipart.ccline 1575 (m_flag_data_before = true;, same message)
The debug message in the second place already says "after", so this looks like a copy-paste slip that has been in both branches since the early-return guard was added.
where it is reachable
- v2:
modsecurity_request_body_store()callsmultipart_process_chunk()once per stored chunk (apache2/msc_reqbody.cline 354), so a body whose closing delimiter ends one bucket and whose epilogue starts the next one takes the early-return path. Whether that split happens depends on how Apache delivers the body (chunked transfer, bucket sizes, proxy buffering), so the same request can yield different variable values on different deployments. - v3:
Transaction::processRequestBody()creates oneMultipartobject and callsprocess()once with the whole buffered body (src/transaction.cclines 775-777), so the early return never runs today. I confirmed this with a small harness: feeding the body through twoappendRequestBody()calls still reaches the "bytes left" branch and setsMULTIPART_DATA_AFTER. The v3 line is dead code, but it should be fixed too so the two branches stay in sync and it does not bite if chunked processing is ever introduced.
effect (v2)
For a request whose body is delivered as ...--BOUNDARY--\r\n in one bucket and the epilogue in the next:
MULTIPART_DATA_AFTERstays0, so a rule on it does not fire.MULTIPART_DATA_BEFOREbecomes1, which is misleading in the audit log.MULTIPART_STRICT_ERRORstill fires, since it includes both flags, so blocking with the recommended rule 200003 is unaffected.- The epilogue is never scanned for boundary-like lines, so it cannot affect
MULTIPART_UNMATCHED_BOUNDARY. The same is true within a single chunk, so that part is at least consistent.
proposed regression test (v2)
SecRule MULTIPART_DATA_AFTER "!@eq 0" "id:1,phase:2,deny,status:403" and SecRule MULTIPART_DATA_BEFORE "!@eq 0" "id:2,phase:2,deny,status:402", body sent as two chunks:
--0000\r\nContent-Disposition: form-data; name="a"\r\n\r\nx\r\n--0000--\r\ntrailing garbage\r\n
Expected 403. By code reading the second chunk hits the early return and the request is answered 402 with "Ignoring data after last boundary (received 18 bytes)" in the debug log. I have not yet run this under Apache; the Perl regression framework sends the body in one piece, so the test needs a chunked request.
fix
Set the after flag on the early-return path in both branches. One-line change each, plus the test above for v2. Noticed while reviewing #3658; it is independent of that PR and predates it.
- Lingua principale
- C++
- Stelle
- 9.8k
- Fork
- 1.8k
- Merge medio
- 1g 1h
- PR unite (30g)
- 13
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di owasp-modsecurity/ModSecurity
-
v2: t:utf8toUnicode drops the last hex digit of code points above U+FFFF (regression since 2.9.9)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
owasp-modsecurity/ModSecurity#3684 ·
I maintainer di solito rispondono entro 1 giorno
-
IIS: ReadFileChunk allocates only 1 byte but reads m_dwPageSize (latent overflow)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta2.x bug Platform - IIS pr available windows
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
owasp-modsecurity/ModSecurity#3623 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
IIS: Host header fallback is dead code (r->hostname == NULL can never be true)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta2.x bug Platform - IIS pr available windows
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
owasp-modsecurity/ModSecurity#3621 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
IIS: Content-Length header corrupted/truncated for large responses (wrong printf format + off-by-one buffer size)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta2.x bug Platform - IIS pr available windows
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
owasp-modsecurity/ModSecurity#3619 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
2.x bug Platform - IIS pr available windows
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
owasp-modsecurity/ModSecurity#3612 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di owasp-modsecurity/ModSecurity
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Mac mini M6 (16 GB): Q2_0 streaming works - measured 11.7->27.2 tok/s + arena fix for sub-32 GB MacsAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
champion good first issue remake source/qq
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
metasequoiaime/msime-windows#1025 ·
I maintainer di solito rispondono entro 1 giorno
-
backlog bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
EchoTools/nevr-runtime#653 ·
I maintainer di solito rispondono entro 1 giorno
-
`--fail-require-skip` never fires: run_tests.py searches stdout, but the unittest binary writes the skip summary to stderrForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno