我们正在对我们的应用网址运行合理的应用扫描,并返回以下结果:
似乎Web服务器配置为允许一个(或多个)以下HTTP方法(动词) - DELETE - SEARCH - COPY - MOVE - PROPFIND - PROPPATCH - MKCOL - LOCK - UNLOCK - 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发出的请求
dOp*_*Ops 16
最终有效的简单解决方案
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* - [R=405,L]
这可以让应用程序扫描开心(我也是)
我怀疑Apache正在向Tomcat转发OPTIONS请求(它获取可能支持的方法的列表).然后,您将获得默认的HttpServlet实现doOptions,它显然会在其中返回一个Allow标头TRACE.
您可以覆盖doOptions以TRACE从这个误导性列表中删除,例如匹配Apache:
response.setHeader("Allow", "OPTIONS, GET, HEAD, POST");
或者,如果您确定不需要任何其他功能(例如CORS预飞行),您可以完全阻止OPTIONS.顺便提一下,您还可以将limit与mod_access一起使用来限制对所需方法的访问,而不必在mod_rewrite处理链中进行拖动.
或者:如果您确定您实际上没有TRACE或任何其他不需要的方法可用,您可以忽略该发现.AppScan的试图警告你,它看起来像有可能会有一些危险方法可用,但它实际上并没有发现漏洞等.具有OPTIONS实际不起作用的返回方法是不合需要的,但这不是真正的安全问题.
小智 5
我们最初在Apache的httpd.conf中的conf下面设置了禁用易受攻击的HTTP方法[TRACE | TRACK | PUT | DELETE | CONNECT | OPTIONS]，但它对我们不起作用：
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>