我有以下表格，其中发布了 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 拒绝请求，因为
需要"eq 0"与"MULTIPART_UNMATCHED_BOUNDARY"匹配
我假设 mod 安全性正在考虑一旦它击中 EOF 字符就完成的请求。
我不想告诉所有用户，如果他们收到 403 错误以重新创建文件，希望它不包含 EOF 字符。
我有哪些选择？浏览器可以通过 html 表单中的某些设置以某种方式对文件进行编码，以便 modsecurity 看不到 EOF 字符吗？或者是否可以将 mod 安全性配置为忽略 EOF 字符，直到 POST 请求真正完成？
尽管我对@ahjohnston25此问题的修复/解决方法没有任何要添加的内容，但我希望可以阐明问题的根本原因。
过去，有些MIME解析器的错误可以通过在数据流中粘贴CR-LF-dash-dash来跳闸，因为它们会将任何以"--"开头的行视为MIME部分分隔符。MULTIPART_UNMATCHED_BOUNDARY检测到这种情况。
我已经很多年没有见过这么糟糕的MIME解析器了，所以我觉得在我维护的系统上删除规则960915（及其表亲200003）是安全的。
事实证明，PDF 会将一些数据流编组成包含换行符-破折号-破折号的字符串，因此使用 PDF 上传来打这个误报的变化比使用 JPEG 时更大（但我也见过这个触发器与 JPEG 一起，运气好）。鉴于在当今的网络中，MIME上传没有其他选择（除了要求用户压缩所有PDF），将规则列入白名单是使PDF上传可靠的唯一方法。
当您有一个重现问题的 PDF 文件时，请帮自己一个忙并保存它。在您的开发盒上获取 modsecurity 并重现问题。然后，在禁用此规则的情况下，尝试将其上传到应用并进行校验和。如果您没有看到任何损坏，则您已证明此特定代码路径不会在看起来像 MIME 标头的行上跳闸，您可以尝试说服您的系统管理员为您的特定 URI 设置异常。
如果他拒绝，就沿着管理链往上走，解释你已经做了功课，而他没有。如果他拒绝并且您有客户/供应商关系，请考虑更换供应商。
重现此类问题节省了我的培根，例如，当用户抱怨无法上传文件名中带有引号的文件时。我可以重现该问题，但是在我的开发系统上删除规则后，我在尝试上传有问题的文件时看到了SQL错误。哎呀。不确定Joomla是否同时修复了该错误，但就目前而言，该特定规则仍然存在。
扬子晚报.
虽然不是最佳选项，但您可以通过运行以下命令来禁用规则（规则 ID 为 #960915）：
echo "SecRuleRemoveById 960915" >> /etc/httpd/conf.d/modsecurity.conf
或者无论你的modsecurity.conf文件在哪里。
编辑：更新了该行以使用modsecurity.conf的位置进行特定安装。我将保留上述行，因为它的位置没有标准化。