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

http://www.myhack58.com/Article/html/3/8/2015/62279_17.htm
?什么是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


<security-constraint>
? ? <web-resource-<a?


href="http://resources.infosecinstitute.com/collection/">collection</a


>>
? ? <url-pattern>/auth/*</url-pattern>
? ? <http-method>GET</http-method>




<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
? ? <role-name>root</role-name>
</auth-constraint>
</security-constraint>
?
這樣的設定是告訴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
?
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請求的響應。


任意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


科普：繞過Web授權和認證之篡改HTTP請求
來源：Sobug漏洞時間 作者：佚名 時間：2015-05-12 TAG： 我要投稿
?
表面上，允許使用HEAD方法并不是一個漏洞，因為RFC也有這種要求。讓我們來


看看一些最流行的應用安全機制是否會給我們繞過VBAAC以可乘之機。如下是一


些可能會受到篡改請求影響的服務器：
?
服務器類型
是否允許HTTP請求？
是否可繞過？
HEAD請求是否可用？
JAVA EE
YES
YES
YES
.htaccess
YES
YES（默認配置）
YES
ASP.NET
YES
YES（默認配置）
YES




如何防范HTTP Verb Tampering
?
如何防范HTTP Verb Tampering JAVA EE容器，讓我們來看看如下安全約束策略


：
?
<security-constraint>
<display-name>Example Security Constraint Policy</display-name>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected -->
<url-pattern>/auth/security/*




</url-pattern>
<!-- If you list http methods, only those methods are protected -->
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
</web-resource-collection>
...
</security-constraint>
?
以上代碼中，偉大的攻城獅列舉并限制了POST, PUT, DELETE, GET等方法。因此


，只有當瀏覽器使用這些在<http-method>表中列舉出的請求去獲


取/auth/security/*路徑下文件時才會觸發安全約束策略。
?
因此，把其他未列出的方法也一并禁用才是完善這條規則的最優解。遺憾的是，


以上策略目前卻并非如此嚴謹。比如，由于HEAD并沒有被列舉出來，利用HEAD請


求不難繞過此策略。確保JAVA EE安全性的正確打開方式是從安全約束策略中去


除所有<http-method>，并使安全約束策略針對所有的HTTP請求方法。但如果您


仍想限制某些特定方法，建議您參考如下方法，分2步創建安全約束策略。


<security-constraint>
? ? <web-resource-collection>
? ? ? ? <web-resource-name>site</web-resource-name>
? ? ? ? <url-pattern>/*</url-pattern>
? ? ? ? <http-method>GET</http-method>
? ? </web-resource-collection>
...
</security-constraint>
<security-constraint>
? ? <web-resource-collection>




<web-resource-name>site</web-resource-name>
? ? ? ? <url-pattern>/*</url-pattern>
? ? </web-resource-collection>
...
</security-constraint>
?
如上，第1條策略將拒絕GET請求，而第2條策略則拒絕所有請求方法。
?
ASP.NET授權
?
我們知道ASP.NET授權的安全機制是可能被繞過的，舉幾個例子來說明吧。


<authorization>
? ? <allow verbs="POST" users="joe"/>
? ? <allow verbs="GET" users="*"/>
? ? <deny verbs="POST" users="*"/>
</authorization>


在上面這段代碼中：
?
允許用戶joe發送POST請求
允許所有用戶發送GET請求
拒絕所有用戶發送POST請求
?
由于第2條允許所有用戶發送GET請求，都無需用HEAD繞過了，簡直毫無安全性可


言。不要覺得你的智商被侮辱了，我們繼續往下看。以下代碼做了部分限制，但


仍然會被HEAD繞過。
?
<authorization>
? ? <allow verbs="GET" users="root"/>


<allow verbs="POST" users="joe"/>
? ? <deny verbs="POST,GET" users="*" />
</authorization>
?
原因是逐條匹配以下規則后，發現HEAD請求不在限制范圍內。
?
允許用戶root發送GET請求
允許用戶joe發送POST請求
拒絕所有用戶發送POST, GET請求


由于.NET會悄悄地在所有規則的最后插入一條規則允許所有用戶發送所有請求。


因此，HEAD請求會被放行。為避免這種情況，我們應該在最后一條規則后加上“


拒絕所有用戶發送所有請求”。于是，有了如下代碼：
?
<authorization>
? ? <allow verbs="GET" users="root"/>
? ? <allow verbs="POST" users="joe"/>
? ? <deny verbs


="*" users="*" />
</authorization>
?
這樣才能完全確保只有那些在規則白名單中的特定用戶才被允許發送特定HTTP請


求。
?
總結
?
在業務許可的情況下，加上”deny all”。


?
配置你的web服務器和應用服務器完全禁用HEAD請求。
?
轉載請注明原文出自SOBUG眾測平臺，并附帶本文鏈接。


原文參考：
http://resources.infosecinstitute.com/http-verb-tempering-bypassing-


web-authentication-and-authorization/


========

關于繞過web認證的一點思路

想必大家應該知道cmcc和chinanet之類的連進去之后會自動彈出賬戶密碼輸入界

面，現在很多的路由器都自帶這種web認證功能。在某論壇看到，dns隧道技術。

通過請求dns查詢數據包上網。本人親測，磊科nr235w路由器，自帶web認證功能

的路由器，繞過認證上網。在這發帖是希望找到朋友共同研究，做出能滿足普通

人快速接入上網的軟件。先介紹我用的方法。叫做dns隧道技術.大家接入認證的

路由后，可以cmd試試ns lookup baidu.com查詢一下百度地址，如果出現ip證明

dns數據查詢的請求是可用的。需要dns服務器.有些網站提供免費的dns解析，例

如freedns.一定要帶ns解析。通過ns記錄解析到網址'網址再解析到ip到達我們

發送數據包的服務器...(因為ns記錄不能直接解析ip所以才要解析兩步)然后是

那臺ip的機子，數據交換需要開個代理.例如http代理.把dns解析過來對應的端


口對應到代理端口，就能實現上網，同時需要一個dns和tcp數據轉化軟件例如


tcp-over-dns.hryoka.iodine這三個。。。可能大家有些不理解，因為機子打的


，有些講不清。。。過幾天我發圖文教程哈。
========

繞過授權驗證

　　授權在網絡上的意思是指，對特定資源的讀寫權限。通俗地講，就是你的權


限能讓你做什么事情。而驗證則表示你是否真的可以對這些資源進行讀寫。
　　授權問題是指訪問了沒有授權的資源或信息，也叫作越權。越權又可以分為


兩種：水平越權與垂直越權。
1．水平越權
　　例如，http://www.xxx.org提供了用戶修改資料的功能，當訪問URL：


http://www.xxx.org /userinfo.action?id=2時，將會顯示自己的信息，并且可


以編輯，UserInfo.java源代碼如下：
　　public String ?execute(){
　　int id = this.user.getUserId();
　　this.user = new UserProxy.findUserById(id);
　　return SUCCESS;
　　}
　　這段代碼并沒有對ID做任何驗證，直接接收用戶的ID，然后根據ID來查詢用


戶信息。
　　當提交URL為：http://www.xxx.org/userinfo.action?id=3時，程序就會按


部就班地執行，返回ID為3的User信息到頁面中，這就是水平越權。
　　總的來說，水平越權就是相同級別（權限）的用戶或者同一角色的不同用戶


之間，可以越權訪問、修改或者刪除的非法操作。
　　2．垂直越權
　　
　　垂直越權又被分為向上越權與向下越權。比如，某些網站，像發布文章、刪


除文章等操作是屬于管理員做的事情，假設一個匿名用戶也可以做相同的事情，


這就叫作向上越權。
　　向下越權與向上越權恰恰相反，向下越權是一個高級別用戶可以訪問一個低


級別的用戶信息。這樣做似乎沒錯，而且很多網站都是這么做的，包括低級別密


碼也可以被高級別用戶掌控，但這樣做可以說是完全錯誤！因為即使權限再低的


用戶都有他自己的隱私，可能用戶為了更方便，會將自己的銀行卡號與密碼記錄


在網站中，這些信息都屬于用戶的隱私。
========

總結

以上是生活随笔為你收集整理的绕过web认证学习总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。