一、什么是HTTP请求
超文本传输协议（HTTP）提供了多种请求方法来与web服务器沟通。当然，大多数方法的初衷是帮助开发者在开发或调试过程中部署和测试HTTP应用。如果服务器配置不当，这些请求方法可能被用于一些不法用途。比如：跨站跟踪（XST）是一种高危漏洞，这种跨站脚本能利用HTTP TRACE请求。
GET和POST是开发者获取服务器信息的最常用请求，没有之一。
可以列举出常用HTTP请求：HEAD、GET、POST、PUT、DELETE、TRACE、OPTIONS、CONNECT
理论上，由于这些请求允许攻击者修改web服务器上存储的文件、或者删除服务器上web页面、甚至上传web shell并获取用户的身份信息，它们都有可能制造出严重的安全漏洞。
另外出于安全考虑，服务器root权限必须禁用如下请求：
PUT：允许上传新文件至web服务器。攻击者可以上传恶意文件（比如可以执行调用cmd.exe命令的ASP/PHP文件）或者将受害者服务器用于存储自己的文件。
DELETE：允许删除web服务器上的文件。攻击者可以简单粗暴的丑化受害者网站或实施DDoS攻击。
CONNECT：允许客户端将服务器配置为代理。
TRACE：可以在客户端上回显任何发送到服务器上的字符串。这个请求本来是用于帮助开发者调试的。但这个看似人畜无害的请求，却被Jeremiah Grossman发现可以被利用以实施XST攻击。
即使一些Web服务经常会用到PUT或DELETE请求，但当我们真的遇到如上请求时，务必谨慎一些，确认这些请求是由可信用户在安全的环境中发出的。很多网络环境使用基于请求的认证及访问控制策略（VBAAC）。但是否会被绕过呢？我们来看下面这个例子：
JAVA EE web XML file <web-resource-<< span="">a href="http://resources.infosecinstitute.com/collection/">collection> /auth/* GET POST root
这样的设定是告诉HTTP Servlet的Container，仅允许用户角色为root的使用者，通过GET和POST的请求，获取路径为/auth/*下的资源。乍一看，代码限定了用户访问权限，好像没什么问题。但是，我们却可以通过篡改HTTP请求来绕过限制！为何？因为他并没有限制其他的HTTP请求应该被服务器拒绝！
我们可以用HEAD或者其他非GET/POST请求，诸如PUT, TRACK, TRACE, DELETE等，或者还可以尝试发送任意字符串（如ASDF），无比轻松的绕过这条规则，达到获取/auth/*路径下文件的目的。
总结一下可能会发生绕过的情形：
允许非等幂的GET请求或者允许任意HTTP方法
仅通过列出HTTP请求来控制安全
不禁用没有列出的HTTP请求
以上是发生绕过的几种最常见情形。各种排列组合或细节差异随实际的服务器配置而千变万化。但万变不离其宗，看似复杂的实际案例背后的原理却是相同的。
二、如何利用HTTP Verb Tampering绕过VBAAC
1、HEAD请求
如上所述，HEAD请求与GET类似，只不过服务器在响应时不会返回消息体。设想你的应用中有一段URL，若仅通过“拒绝GET和POST获取/auth路径下文件”这条规则保护，仍然是极不安全的。
http://httpsecure.org/auth/root.jsp?cmd=adduser
如果你强制浏览器访问该URL，安全机制会被触发，检查请求资源和请求者是否符合授权规则。第一个当然就是检查并阻断浏览器发送的GET和POST请求了。这时，只要你使用浏览器代理，比如Suite Burp，将拦截下来的GET请求替换成HEAD。由于HEAD未被列入安全约束规则中而畅行无阻，因此adduser命令将被成功调用，而你的浏览器也将得到一个空消息体作为HEAD请求的响应。
2、任意HTTP请求
包括PHP, JAVA EE在内的大多数平台都默认允许使用任意的HTTP请求。而这些请求可以取代GET绕过规则。更可怕的是，使用任意HTTP请求可以让你看到内部页面，甚至是网页源码，而这些是HEAD办不到的。某些服务器厂商允许HEAD请求，如下服务器厂商默认允许HEAD请求：
APACHE 2.2.8
JBOSS 4.2.2
WEBSPERE 6.1
TOMCAT 6.0
IIS 6.0
WEBLOGIC 8.2
表面上，允许使用HEAD方法并不是一个漏洞，因为RFC也有这种要求。让我们来看看一些最流行的应用安全机制是否会给我们绕过VBAAC(verb-based authentication and access control )以可乘之机。如下是一些可能会受到篡改请求影响的服务器：
服务器类型 是否允许HTTP请求？ 是否可绕过？ HEAD请求是否可用？
JAVA EE YES YES YES
.htaccess YES YES（默认配置） YES
ASP.NET YES YES（默认配置） YES
三、如何防范HTTP Verb Tampering
3.1 JAVA 安全约束
如何防范HTTP Verb Tampering JAVA EE容器，让我们来看看如下安全约束策略：
Example Security Constraint Policy Protected Area /auth/security/* POST PUT DELETE GET ...
以上代码中，工程师列举并限制了POST, PUT, DELETE, GET等方法。因此，只有当浏览器使用这些在表中列举出的请求去获取/auth/security/*路径下文件时才会触发安全约束策略。
因此，把其他未列出的方法也一并禁用才是完善这条规则的最优解。遗憾的是，以上策略目前却并非如此严谨。比如，由于HEAD并没有被列举出来，利用HEAD请求不难绕过此策略。确保JAVA EE安全性的正确打开方式是从安全约束策略中去除所有，并使安全约束策略针对所有的HTTP请求方法。但如果您仍想限制某些特定方法，建议您参考如下方法，分2步创建安全约束策略。
site /* GET ... site /* ...
如上，第1条策略将拒绝GET请求，而第2条策略则拒绝所有请求方法。
3.2、ASP.NET授权
我们知道ASP.NET授权的安全机制是可能被绕过的，举几个例子来说明吧。
<allow verbs="POST" users="joe"/> <allow verbs="GET" users="*"/> <deny verbs="POST" users="*"/>
在上面这段代码中：
允许用户joe发送POST请求
允许所有用户发送GET请求
拒绝所有用户发送POST请求
由于第2条允许所有用户发送GET请求，都无需用HEAD绕过了，简直毫无安全性可言。不要觉得你的智商被侮辱了，我们继续往下看。以下代码做了部分限制，但仍然会被HEAD绕过。
<allow verbs="POST" users="root"/> <allow verbs="GET" users="joe"/> <deny verbs="GET,POST" users="*"/>
原因是逐条匹配以下规则后，发现HEAD请求不在限制范围内。
允许用户root发送GET请求
允许用户joe发送POST请求
拒绝所有用户发送POST, GET请求
由于.NET会悄悄地在所有规则的最后插入一条规则允许所有用户发送所有请求。因此，HEAD请求会被放行。为避免这种情况，我们应该在最后一条规则后加上“拒绝所有用户发送所有请求”。于是，有了如下代码：
<allow verbs="POST" users="root"/> <allow verbs="GET" users="joe"/> <deny verbs="*" users="*"/>
这样才能完全确保只有那些在规则白名单中的特定用户才被允许发送特定HTTP请求。
总结：
在业务许可的情况下，加上”deny all”。
配置你的web服务器和应用服务器完全禁用HEAD请求。