繞過Web授權和認證之篡改HTTP請求

標籤：

一、什麼是HTTP請求 　　

　　超文字傳輸通訊協定 (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/*GETPOST 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 PolicyProtected Area/auth/security/*POSTPUTDELETEGET...

　　以上代碼中，工程師列舉並限制了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請求。

繞過Web授權和認證之篡改HTTP請求