Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Multipart: data after the final boundary in a later chunk sets MULTIPART_DATA_BEFORE instead of MULTIPART_DATA_AFTER

未关闭
  • 哪里不对？
#3,695 1 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@airween 已经在做这个了。

开始于 2026年10月15日。

评估

这个 Issue 还没有评估数据。

描述

2.x 3.x bug

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.c line 1382 (msr->mpd->flag_data_after = 1;)
  • v3: src/request_body_processor/multipart.cc line 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.c line 1158 (msr->mpd->flag_data_before = 1;, debug message "Ignoring data after last boundary")
  • v3: src/request_body_processor/multipart.cc line 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() calls multipart_process_chunk() once per stored chunk (apache2/msc_reqbody.c line 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 one Multipart object and calls process() once with the whole buffered body (src/transaction.cc lines 775-777), so the early return never runs today. I confirmed this with a small harness: feeding the body through two appendRequestBody() calls still reaches the "bytes left" branch and sets MULTIPART_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_AFTER stays 0, so a rule on it does not fire.
  • MULTIPART_DATA_BEFORE becomes 1, which is misleading in the audit log. MULTIPART_STRICT_ERROR still 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:

  1. --0000\r\nContent-Disposition: form-data; name="a"\r\n\r\nx\r\n--0000--\r\n
  2. trailing 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.

主要语言
C++
星标
9.8k
派生
1.8k
平均合并
1 天 3 小时
30 天内合并 PR
16

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

owasp-modsecurity/ModSecurity 的其他 Issue

查看 owasp-modsecurity/ModSecurity 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。