我们正在对我们的应用程序URL运行rational app scan,它返回以下结果:
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>
但是rational应用程序扫描仍然显示这是一个问题。有人遇到过同样的问题吗?这个URL通过AJP转到Tomcat后端。希望能解决这个问题。
PS:我有限制和LimitExcept在脑海中,但我不确定它是否会阻止通过mod_proxy或mod_jk的请求
4条答案
按热度按时间kxkpmulp1#
最后奏效的简单解决方案
这让应用程序扫描高兴(和我一样)
vxqlmq5t2#
我怀疑Apache正在向Tomcat转发OPTIONS请求(获取可能支持的方法列表)。然后您将获得
doOptions
的默认HttpServlet实现,它显然返回一个Allow
头,其中包含TRACE
。你可以覆盖
doOptions
来从这个误导性的列表中删除TRACE
,例如匹配Apache:或者,如果你确定你不需要OPTIONS的任何其他功能(例如CORS pre-flighting),你可以完全阻止OPTIONS。顺便说一句,你也可以使用Limit和mod_access来限制对所需方法的访问,而不必在mod_rewrite处理链中拖动。
或者:如果你确定你实际上没有
TRACE
或任何其他不需要的方法可用,你可以忽略这个发现。AppScan试图警告你,它 * 看起来 * 可能 * 有一些危险的方法可用,但它实际上并没有发现这样的漏洞。让OPTIONS
返回实际上不工作的方法是不可取的,但这不是真实的的安全问题7ivaypg93#
我们最初在Apache的httpd.conf中设置了below conf,以禁用易受攻击的HTTP方法[TRACE|轨道|PUT|删除|联系我们|但它对我们不起作用:
现在,我们已经设置了以下规则及其工作:
hivapdat4#
我认为AppScan和所有扫描器都使用OPTIONS指令来找出启用的方法。你可能需要在重写规则中添加它。
最好的方法是仔细阅读文档并完全禁用这些方法。
干杯,扎克