Apache – 如何限制Content-Type标题长度以避免CVE-2014-0050？

周四Tomcat邮件列表（ “[SECURITY] CVE-2014-0050 Apache Commons FileUpload和Apache Tomcat DoS” ）宣布Tomcat的DoS问题。

当我上传文件时（如果在Web应用程序中使用Servlet 3.0+上传function），攻击者似乎能够通过发送超长的content-type标头来导致无限循环，就我所了解的信息而言乍一看。

如果有人在Apache httpd服务器（使用AJP和mod_jk）后面运行他们的Tomcat服务器，那么可以采取什么措施来实现build议“将Content-Type头限制为小于4091字节” ？

当然，只要修补程序版本可用（通过下载页面或Linux发行版特定软件包存储库），就应该更新。没有问题。但目前可用的Tomcat 7.0.50版本似乎仍然受到影响。

但是，在固定版本发布之前，作为一种快速防御措施，可以做些什么呢？

（不必…

卸载当前的Tomcat软件包（从软件包仓库安装），
从源代码（SVN）手动构build版本，
手动部署（不带apt-get或aptitude ），
稍后再次卸载所有手动构build的东西，以便从软件包存储库中获得舒适的可更新版本）

有没有类似于这个主题的临时解决方法： http : //wiki.apache.org/httpd/CVE-2011-3192 ？

那么，可以使用mod_headers ， mod_setenvif或mod_rewrite来处理这个问题。是否有类似的Apache httpd技巧来保持畸形的分段上传请求远离下游Tomcat服务器？

apache（包括Shane的修改版本;阅读rfc我不会打赌Content-String的长度总是<129

 RewriteEngine On RewriteCond %{HTTP:Content-Type} "multipart\/form-data;(\s*)boundary=[a-zA-Z0-9_-]{3000}" RewriteRule ^/(.*)$ /405.html [R=301,L] # modified SetEnvIf Content-Type ^.{3000,}$ bad-content-type=1 RequestHeader unset Content-Type env=bad-content-type

nginx（没有find解决方法if（））

 server { ... if ($http_content_type ~* "multipart\/form-data;(\s*)boundary=[a-zA-Z0-9_-]{3000}" ) { return 403; } ... }

是的，这应该工作。 CVE宣布4091字节，但意外披露邮件似乎是开发者倾向于70-128字节的限制。让我们一起去128，但可以根据需要进行调整：

 SetEnvIf Content-Type ^.{129,}$ bad-content-type=1 RequestHeader unset Content-Type env=bad-content-type

只是取消标题（而不是完全的403请求）可能是不必要的温和与明显的攻击要求，但这应该做的工作。