我有以下表单，其中发布了 2 个字段和一个文件。
<form id="uploadNewForm" action="/upload-new" method="POST" enctype="multipart/form-data" novalidate="novalidate">
<select id="customerNumber" name="customerNumber"><option value="0001">0001</option></select>
<input id="file" name="file" type="file" value="">
<input type="submit" value="Upload" name="fileUpload">
<textarea id="comments" name="comments" maxlength="1000" style="height: 100%;"></textarea>
</form>
一位用户最近试图上传一个包含 EOF 字符的 .pdf 文件。这似乎导致 mod-security 因
而拒绝请求Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required
我假设 mod 安全性正在考虑一旦遇到 EOF 字符就完成的请求。
我不想告诉所有用户，如果他们遇到 403 错误时重新创建文件，希望它不包含 EOF 字符。
我有哪些选择？浏览器能否通过 html 表单中的某些设置以某种方式对文件进行编码，以便 modsecurity 看不到 EOF 字符？还是可以将 mod 安全配置为在 POST 请求真正完成之前忽略 EOF 字符？
最佳答案
虽然我没有任何要添加到@ahjohnston25 针对此问题的修复/解决方法的内容，但我希望可以阐明问题的根本原因。
过去，有些 MIME 解析器存在错误，可以通过在数据流中插入 CR-LF-dash-dash 来解决这些错误，因为它们会将以“--”开头的任何行视为 MIME 部分分隔符。 MULTIPART_UNMATCHED_BOUNDARY 检测到这种情况。
我已经很多年没见过写得这么糟糕的 MIME 解析器了，所以我觉得可以安全地删除我维护的系统上的规则 960915(及其表亲 200003)。
事实证明，PDF 会将一些数据流编码为包含换行符-破折号-破折号的字符串，因此与 JPEG 相比，使用 PDF 上传时命中此误报的变化更大(但我已经也看到了这个带有 JPEG 的触发器，祝你好运)。鉴于在当今的网络中除了 MIME 上传之外别无选择(除了要求您的用户压缩所有 PDF 之外)，将规则列入白名单是使 PDF 上传可靠的唯一方法。
当您有一个重现该问题的 PDF 文件时，请帮自己一个忙并保存它。在您的开发盒上获取 modsecurity 并重现该问题。然后，在禁用此规则的情况下，尝试将其上传到您的应用程序并对其进行校验和。如果您没有看到任何损坏，您已经证明这个特定的代码路径不会越过看起来像 MIME header 的行，并且您可以尝试说服您的系统管理员为您的特定 URI 设置一个异常(exception)。
如果他拒绝，请沿着管理链往上爬，解释说你已经完成了功课而他没有。如果他拒绝并且您有客户/供应商关系，请考虑更换供应商。
重现此类问题救了我的命，例如，有一次用户提示无法上传文件名中包含引号的文件。我可以重现这个问题，但是在我的开发系统上删除规则后，我在尝试上传有问题的文件时看到了 SQL 错误。哎呀。不确定 Joomla 是否同时修复了该错误，但目前该特定规则仍然有效。
YMMV.
关于html - 文件上传中的 EOF 字符导致 mod 安全返回 403，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28199446/