一、什么是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請求。
3.3 Asp.Net MVC
須在 Controller 的 Action 添加授權。