Html 文件上载中的EOF字符导致mod security返回403

我有下面的表单，发布了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>

0001

一位用户最近试图上传一个.pdf文件，其中包含一个EOF字符。这似乎已导致国防部安全部门拒绝请求，原因是：

需要将“等式0”与“多部分\u不匹配\u边界”匹配

我假设mod security正在考虑一旦到达EOF字符就完成的请求

我不想告诉所有用户，如果他们在重新创建文件时出现403错误，希望文件不包含EOF字符

---

我有什么选择？浏览器是否可以通过html表单中的某些设置对文件进行编码，以便modsecurity不会看到EOF字符？或者可以将mod security配置为在POST请求真正完成之前忽略EOF字符吗？

虽然不是最佳选项，但可以通过运行以下命令禁用规则（规则ID为#960915）：

echo "SecRuleRemoveById 960915" >> /etc/httpd/conf.d/modsecurity.conf

或者modsecurity.conf文件所在的位置

---

编辑：更新该行以使用modsecurity.conf的位置进行特定安装。我将保留上面这一行，因为它的位置不标准。

虽然我没有任何东西可以添加到@ahjohnston25的修复/解决方案中，但我希望能够阐明问题的根本原因

过去，有一些MIME解析器存在错误，如果在数据流中粘贴CR LF dash dash，可能会导致错误，因为它们会将任何以“-”开头的行视为MIME部分分隔符。多部分\u不匹配\u边界检测到这种情况

我已经好几年没见过这么糟糕的MIME解析器了，所以我觉得在我维护的系统上删除规则960915（及其表兄200003）是安全的

事实证明，PDF会将一些数据流整理成包含换行符破折号的字符串，因此，与JPEG相比，PDF上传的误报率有更大的变化（但我也看到了JPEG的这一触发点，祝你好运）。在当今的网络中，除了MIME上传（除了要求用户压缩所有PDF之外），没有其他选择，因此将规则列入白名单是确保PDF上传可靠的唯一方法

当你有一个PDF文件可以复制这个问题时，帮你自己一个忙并保存它。在你的开发箱上安装modsecurity并复制这个问题。然后，禁用此规则，尝试将其上载到应用程序并对其进行校验和。如果您没有看到任何损坏，那么您已经证明了这个特定的代码路径不会在看起来像MIME头的行上绊倒，并且您可以尝试说服您的系统管理员为您的特定URI设置一个异常

如果他拒绝，向你解释你已经做了功课，而他没有做。如果他拒绝并且你有一个客户/供应商关系，考虑切换供应商。 复制这些问题拯救了我的培根，例如，当用户抱怨无法上传文件名中带有引号的文件时。我可以重现这个问题，但在删除开发系统上的规则后，我在尝试上载有问题的文件时看到了一个SQL错误。哎呀。不确定Joomla是否在同一时间修复了这个bug，但现在，这个特定的规则仍然存在

---

YMMV.

您知道（或者您能找到）此规则的规则ID吗？我是开发人员，只能访问某些日志。在我们的日志显示应用程序中，我看到以下内容。消息：使用代码403（阶段2）访问。需要将“eq0”与“多部分未匹配的边界”匹配。[file”/etc/httpd/conf.d/mod_security.conf“][line“96”][msg“multipartparserdetectedableunmatchedboundary.”操作：截获（第2阶段）Apache处理程序：weblogic处理程序管理员不愿意删除该规则或将其设置为仅记录。您可以使用

标记禁用特定路径的规则除此之外，我认为没有其他选择（因为您无法控制表单的输入内容）。