为什么要禁止除GET和POST之外的HTTP方法？

最近老是听朋友说，被上级单位通报HTTP不安全方法漏洞，本来是低危漏洞，也没怎么注意它，最近升为中危漏洞，每天催着去整改，闹得人心惶惶，甚至经常被维护人员吐槽，做的是得不偿失的事情。

因此，有必要说明一下，为什么要禁止除GET和POST之外的HTTP方法。

换句话说，对于这些HTTP不安全方法，到底有多不安全呢？

一、HTTP请求方法有哪些

根据HTTP标准，HTTP请求可以使用多种方法，其功能描述如下所示。

HTTP1.0定义了三种请求方法： GET、POST、HEAD

HTTP1.1新增了五种请求方法：OPTIONS、PUT、DELETE、TRACE 、CONNECT

二、举例说明不安全的HTTP方法

众所周知，GET、POST是最为常见方法，而且大部分主流网站只支持这两种方法，因为它们已能满足功能需求。其中，GET方法主要用来获取服务器上的资源，而POST方法是用来向服务器特定URL的资源提交数据。而其它方法出于安全考虑被禁用，所以在实际应用中，九成以上的服务器都不会响应其它方法，并抛出404或405错误提示。以下列举几个HTTP方法的不安全性：

1、OPTIONS方法，将会造成服务器信息暴露，如中间件版本、支持的HTTP方法等。

2、PUT方法，由于PUT方法自身不带验证机制，利用PUT方法即可快捷简单地入侵服务器，上传Webshell或其他恶意文件，从而获取敏感数据或服务器权限。

3、DELETE方法，利用DELETE方法可以删除服务器上特定的资源文件，造成恶意攻击。

三、漏洞验证

（一）环境搭建

1、测试环境为：WIN10 64位、Tomcat 7.0.72、curl 7.49

2、在Tomcat 7默认配置中，web.xml文件的org.apache.catalina.servlets.DefaultServlet的

readonly参数默认是true，即不允许DELETE和PUT操作，所以通过PUT或DELETE方法访问，就会报403错误。为配合测试，把readonly参数设为false。

（二）漏洞利用

1、PUT上传和DELETE删除文件成功

在DefaultServlet的readonly参数为falsed的情况下，使用Curl进行测试，发现已能通过PUT上传和DELETE删除文件。

2、直接PUT上传.jsp失败

此时想直接上传webshell.jsp，但发现上传失败。

研究发现，原因是在默认配置下，涉及jsp、jspx后缀名的请求由org.apache.jasper.servlet.JspServlet处理，除此之外的请求才由org.apache.catalina.servlets.DefaultServlet处理。

刚才将DefaultServlet的readonly设置为false，并不能对jsp和jspx生效。因此，当PUT上传jsp和jspx文件时，Tomcat用JspServlet来处理请求，而JspServlet中没有PUT上传的逻辑，所以会403报错。

3、利用漏洞成功上传WebShell

对于不能直接上传WebShell的问题，一般的思路是通过解析漏洞来解决，而不少中间件版本如IIS 6、TOMCAT 7等都出现过相关的漏洞。

在此测试环境中，利用Tomcat 7的任意文件上传漏洞（CVE-2017-12615）来实现目的，该漏洞通过构造特殊后缀名，绕过tomcat检测，让它用DefaultServlet的逻辑处理请求，从而上传jsp文件。具体来说，主要有三种方法，比如shell.jsp%20 、shell.jsp::$DATA 、shell.jsp/

本次测试，使用第一种方法，在1.jsp后面加上%20，如此即可成功实现上传，并取得WebShell。

curl -X PUT http://127.0.0.1:8080/examples/1.jsp%20 -d “HelloJSP”