HTTP漏洞

不安全的HTTP方法¶

我们常见的HTTP请求方法是GET、POST和HEAD。但是，其实除了这两个之外，HTTP还有一些其他的请求方法。

WebDAV （Web-based Distributed Authoring and Versioning）一种基于 HTTP 1.1协议的通信协议。它扩展了HTTP 1.1，在GET、POST、HEAD等几个HTTP标准方法以外添加了一些新的方法，使应用程序可对Web Server直接读写，并支持写文件锁定(Locking)及解锁(Unlock)，还可以支持文件的版本控制。

WebDAV虽然方便了网站管理员对网站的管理，但是也带来了新的安全风险！

PUT：由于PUT方法自身不带验证机制，利用PUT方法可以向服务器上传文件，所以恶意攻击者可以上传木马等恶意文件。
DELETE：利用DELETE方法可以删除服务器上特定的资源文件，造成恶意攻击。
OPTIONS：将会造成服务器信息暴露，如中间件版本、支持的HTTP方法等。
TRACE：可以回显服务器收到的请求，主要用于测试或诊断，一般都会存在反射型跨站漏洞

1-不安全的http方法.jpg

在HTTP认为的那些不安全的HTTP方法中，安全界认为PUT、DELETE、TRACE是不安全的，另外WebDAV中的几个方法，RFC 5789中的PATCH方法也被认为是不安全的。（TRACE容易引发XST攻击，PATCH修改资源的部分内容，PUT/DELETE没有认证机制等原因，不仅仅因为它们会产生结果）

漏洞验证¶

不安全的HTTP方法漏洞检测，分为两步：查询资源支持的方法、验证方法是否真的支持。

查询

在之前的文章里提到过，OPTIONS请求方法可以查询URL指定的资源支持哪些方法。

首先正常请求，抓包，然后将请求包中的请求方法修改为OPTIONS，提交，如果成功，响应包中就会出现一个Allow首部字段，里面列出了URL指定资源所支持的方法列表。

3-不安全的http方法.jpg

执行到这一步，就出现这么一种现象，有的校友在执行OPTIONS请求后，发现响应包的Allow字段中包含了PUT、DELETE等不安全方法，就直接认定系统存在漏洞。在我看来，这是不严谨的。有时候Allow字段提示支持，但实际上并不支持，因此需要进一步验证该资源是否真的支持不安全的HTTP方法。

验证

查询阶段显示，支持TRACE方法。那我们将OPTIONS方法修改为TRACE方法试试，如果响应包主体中包含接收到的请求，则证明支持TRACE方法，系统存在漏洞。

4-不安全的http方法.jpg

5-不安全的http方法.jpg

发现服务器报错，证明并不支持TRACE方法。(不支持一般会报405)

HTTP明文传输漏洞¶

明文传输¶

由于网站在用户提交的敏感数据到服务器的过程中未进行相关加密处理，导致攻击者可以通过中间人攻击（劫持、嗅探）等方式获取到这些未加密的敏感数据。当攻击者获取到这些数据之后，可能利用这些信息以合法用户的身份登录系统，一旦进入到应用系统中那么就可以获取更多的敏感数据，以及有机会发现更多的漏洞。

HTTP 协议¶

HTTP 的传输¶

http 协议的传输是以明文的形式进行传输，从浏览器经中间的各种代理服务器，路由器，防火墙和各种网络的设备之后到达服务器，服务器收到请求再发出响应经过各种网络的设备到达浏览器。这整一个过程都是以明文的形式进行传输。

HTTP 协议的安全风险¶

明文传输就是在通信的过程中所有的东西都是可见的毫无隐私可言，如果在中间的一些环节，有人恶意地去读取通信信息，那就可能会被窃取一些敏感的信息。而这些就包括最为常见的，用户的账户和密码，或者是银行账号和手机号，只要是在通信中出现了这样的数据就可以被取到。

另一种是会被篡改 http 协议的内容，比如，在一个页面中直接插入了一个广告或者小卡片的，而这里小广告通常不是一个静态的图片，而是一个可能带有恶意注入攻击的链接，只要点击了就可能被攻击了或者是再弹出一些乱七八糟的东西。

当然，这种图片也会做得很有诱惑性，我记得以前在做 H5 的时候就出现过这样的情况，当时用的还是 http 协议，我做的一个 H5 页面经反馈平台得知，我的 H5 页面涉及黄色信息我顿时懵逼，打开页面一看，确实直接就在我的页面上盖了一张"36D"图片。

就大致的画个图是这样的：

上面的一中是修改了 DOM ，还有一种是修改或者插入脚本，使页面在加载的时候直接跳到了其他的页面上去或者是修改了 header 使得原本用来防御注入攻击的功能失效。