繞過web認證學習總結
阿新 • • 發佈：2019-02-03
繞過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．垂直越權
垂直越權又被分為向上越權與向下越權。比如，某些網站，像釋出文章、刪
除文章等操作是屬於管理員做的事情，假設一個匿名使用者也可以做相同的事情，
這就叫作向上越權。
向下越權與向上越權恰恰相反，向下越權是一個高級別使用者可以訪問一個低
級別的使用者資訊。這樣做似乎沒錯，而且很多網站都是這麼做的，包括低級別密
碼也可以被高級別使用者掌控，但這樣做可以說是完全錯誤！因為即使許可權再低的
使用者都有他自己的隱私，可能使用者為了更方便，會將自己的銀行卡號與密碼記錄
在網站中，這些資訊都屬於使用者的隱私。
========