不安全的HTTP方法
常见的HTTP请求方法有：
-
- GET：Get长度限制为1024，特别快，不安全，在URL里可见，URL提交参数以？分隔，多个参数用&连接，请求指定的页面信息，并返回实体主体。
- HEAD：类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
- POST：长度一般无限制，由中间件限制，较慢，安全，URL里不可见。请求的参数在数据包的请求body中
- PUT：向指定资源位置上传其最新内容
- DELETE：请求服务器删除指定的页面。
- CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
- OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送‘*‘的请求来测试服务器的功能性。
- TRACE：回显服务器收到的请求，主要用于测试或诊断。
安全隐患：
-
- PUT：由于PUT方法自身不带验证机制，利用PUT方法可以向服务器上传文件，所以恶意攻击者可以上传木马等恶意文件。
- DELETE：利用DELETE方法可以删除服务器上特定的资源文件，造成恶意攻击。
- OPTIONS：将会造成服务器信息暴露，如中间件版本、支持的HTTP方法等。
- TRACE：可以回显服务器收到的请求，主要用于测试或诊断，一般都会存在反射型跨站漏洞
渗透检测：
使用CURL发送OPTIONS请求，查看响应头中的Allow行
命令：curl -I -X OPTIONS http://payloads.online
使用burp等工具
漏洞利用：
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"
然后就直接挂马了，从下图可以看到成功上传webshell.jsp，并成功实现对服务器的控制。