网络安全-使用HTTP动词篡改的认证旁路

这个东西去年的安全扫描都没有，今天就扫出来了，非常奇怪的一个东西。好吧，找资料找原因。结果可能应为搜索名词的原因，这个问题在群友的帮助下解决了。

在我理解中servlet只有post和get方法，然后结果怎么出来这么多奇奇怪怪的方法呢。这些方法干啥的呢？

首先找到的是一个禁用http下不安全的方法的博客，具体谁的博客我也没关注。先按照他的方法修改，修改方法也挺简单，改下tomcat的web.xml就好。

<security-constraint>
    <web-resource-collection>
        <http-method>HEAD</http-method>
        <http-method>PUT</http-method>
        <http-method>DELETE</http-method>
        <http-method>OPTIONS</http-method>
        <http-method>TRACE</http-method>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name></role-name>
    </auth-constraint>
</security-constraint>

为啥要加这个呢！找了下web.xml的说明

WebDAV （Web-based Distributed Authoring and Versioning）是基于 HTTP 1.1 的一个通信协议。它为 HTTP 1.1 添加了一些扩展（就是在 GET、POST、HEAD 等几个 HTTP 标准方法以外添加了一些新的方法），使得应用程序可以直接将文件写到 Web Server 上，并且在写文件时候可以对文件加锁，写完后对文件解锁，还可以支持对文件所做的版本控制。这个协议的出现极大地增加了 Web 作为一种创作媒体对于我们的价值。基于 WebDAV 可以实现一个功能强大的内容管理系统或者配置管理系统。 

好吧，这样就理解了，既然是一个通讯协议增加了这些方法，那么按博主的方法改掉就好了。

可惜事与愿违，使用AppScan扫描还是存在这个问题。那么就纳闷了，为啥会出现这样的情况呢?

于是找到了

AppScan问题“HTTP动词篡改导致的认证旁路”的解决方法

这篇博客，这个里面提供的思路不错，看得出来他也配置了web.xml。这样看起来要升级tomcat的节奏？

如果要升级tomcat我讲面临和那个博主一样的问题，公司层面不好解决，而且公司也不只是用tomcat。其他的应该也存在问题。

从上面可以明显看出来这个漏洞和WebDAV 这个东西其实关系并不大，主要问题在于篡改，WebDAV 只是提供了一些方法，这些方法虽然会导致一些修改或者什么的问题。但是如果是篡改了一个不存在的方法，其实结果也是一样。好吧，其实上面那个博客最大的好处不是认识到了问题的根源，而是找到一个测试神器burpsuite。再也不用苦逼的猜了。

好吧，那么就剩下一个办法，那就是自己写拦截器。拦截住除开get和post的方法。为啥不在web.xml配置这个？因为我试过了配置了之后我自己都登陆不上。

谁配置成功了可以告诉我，我是拿现在这个6.0的tomcat毫无办法。以后考虑升级到9.0。

写拦截器去了，祝福我能成功。

ok,今天加了拦截器，成功干掉了这个问题。

<span style="white-space:pre">	</span> String method = req.getMethod();
        if(!"GET".equals(method)&&!"POST".equals(method)&&!"HEAD".equals(method))
        {
        	log.error("The request with Method["+method+"] was forbidden by server!");
        	response.setContentType("text/html;charset=GBK");
        	response.setCharacterEncoding("GBK");
        	resp.setStatus(403);
		response.getWriter().print("<font size=6 color=red>对不起，您的请求非法，系统拒绝响应!</font>");
        	return;
        }

在burpsuite上面验证，也成功的反应出了正确的消息头。

这里请记住

resp.setStatus(403);

不然是无法通过AppScan的扫描的