Question

我们正在对我们的应用网址运行合理的应用扫描，并返回以下结果：

好像是 Web服务器配置为允许一个（或多个）以下HTTP方法（动词） - 删除 - 搜索 - 复制 - 移动 - PROPFIND - PROPPATCH - MKCOL - 锁 - 开锁 - PUT

为了解决这个问题，我添加了一个RewriteRule以禁止任何这些方法。现在，当我手动测试时，我得到响应代码403：

curl -X PUT https://someurl.com/somecontext/somepage.xhtml

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /somecontext/somepage.xhtml
on this server.</p>
</body></html>

但理性的应用扫描仍然表明这是一个问题。有谁遇到过同样的问题。此URL通过AJP转到tomcat后端。希望解决这个问题。

PS：我考虑过Limit和LimitExcept，但我不确定它是否会阻止通过mod_proxy或mod_jk发出的请求

Answer 1

最终有效的简单解决方案

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* - [R=405,L]

这可以让app扫描感到高兴（还有我）

Answer 2

我怀疑Apache正在向Tomcat转发OPTIONS请求（它获取可能支持的方法的列表）。然后，您获得doOptions的默认HttpServlet实现，该实现显然返回Allow标头，其中包含TRACE。

您可以覆盖doOptions从这个误导性列表中移除TRACE，例如匹配Apache：

response.setHeader("Allow", "OPTIONS, GET, HEAD, POST");

或者，如果您确定不需要任何其他功能（例如CORS预飞行），您可以完全阻止OPTIONS。顺便提一下，您还可以将Limit与mod_access一起使用来限制对所需方法的访问，而不必拖入mod_rewrite处理链。

或者：如果您确定实际上没有TRACE或任何其他不需要的方法，您可以忽略该发现。 AppScan正在试图警告您看起来像那里可能是一些危险的方法，但实际上并没有发现这样的漏洞。使用OPTIONS返回方法实际上不起作用是不可取的，但这不是真正的安全问题。

Answer 3

    RewriteEngine on

    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|PUT|DELETE|CONNECT|OPTIONS)

    RewriteRule .* - [F]

现在，我们已经设置了以下规则及其工作：

 Order allow,deny

 Allow from all

 <LimitExcept POST GET>

       Deny from all

 </LimitExcept>

Answer 4

我认为AppScan和所有扫描程序都使用OPTIONS指令来查找启用的方法。您可能需要在重写规则中添加它。

最好的方法是查看文档并完全禁用这些方法。

干杯，扎克

启用了不安全的HTTP方法 - 如何禁用

4 个答案: