保護Web應用程序不受直接對象引用（DOR

不妨設想一個惡意黑客能夠訪問貴公司所有客戶的賬戶細節，或者使用別人的信用卡在線購物，而這一切只需改變URL中的幾個數字。這聽起來似乎不太可能，但是如果你的Web應用程序容易遭受不安全的直接對象引用的危害，惡意黑客要達到這個目的簡直易如反掌。

不安全的直接對象引用舉例

這里的“對象”是指文件、目錄、數據庫記錄等內部實施的對象，在應用程序將URL（或表單參數）中的一個引用暴露給這些對象之一時，就會發生安全問題。這是因為黑客可以修改這些直接對象引用，例如，黑客可以在一個URL被提交之前進行參數修改，企圖訪問一個不同的、未獲得授權的文件、目錄，或數據庫中的條目。如果不加強其它的授權檢查，這種企圖就會成功。

假設有一個Web應用程序最終會生成下面這個URL：

http://www.yourinsecurewebapp.com/yourgetfile.cfm?filename=yoursometextfile.txt

這里有一個非常明顯的對yoursometextfile.txt文件的直接對象引用。它對黑客的誘惑在于，看到如果將這個文件名換成另外一個文件名（如“yourpasswords.txt”或“youraccounts.txt”）會發生什么。

要取得這種成功，黑客必須正確地猜測出系統上另外一個文件名，但一個更合理的方法，是尋找系統上其它位置的特定內容，其使用的方法就是目錄遍歷攻擊（目錄遍歷是Http的一個安全漏洞，它使得攻擊者能夠訪問受限制的目錄，并能夠在Web服務器的根目錄以外執行命令。）。從本質上講，這意味著訪問一個完全不同的目錄，或者存在漏洞的應用程序的開發者所構建的任何方面。為訪問Apache Tomcat文件名和口令，黑客可能將URL的最后一部分改成：

?filename=../../tomcat/conf/tomcat-users.xml  

并非所有的直接對象引用都提供對文件的訪問。還有另外一種可能激發黑客興趣的URL，其結尾格式如下： 

...account.cfm?customerid=4567 

這會使黑客進一步問，“如果我將客戶ID（customerid）換成4568會發生什么？”

與此類似，如果一個Web應用程序允許一個用戶根據數據庫的關鍵字引用從存儲在數據庫中的一個或多個信用卡中的一個，那么黑客修改此數據庫的關鍵字時，會發生什么呢？ 

<select name="choosecreditcard"> 
 
<option value="56"> 
 
XXXXXXXXXXXX6902  
 
</option> 
 
<option value="88"> 
 
XXXXXXXXXXXX5586  
 
</option> 
 
</select> 

在這里，用戶可以從兩個分別以6902和5586為結尾的卡中選擇一個，該卡號由數據庫的關鍵字引用，而應用程序可以訪問此數據庫文件。因此，黑客可以將56或88改為另一個數字，如78，用來引用屬于另外一個用戶的卡號。如果沒有其它的認證檢查來防止這種引用，攻擊將獲得成功。

避免不安全的直接對象引用

避免不安全的直接對象引用（DOR）漏洞的最佳方法是，完全不要暴露私密的對象引用，但如果非用不可，非常重要的一點是確保在向任何用戶提供訪問之前對其進行認證和審查。全球頂級的Web應用安全機構OWASP建議企業建立一種引用應用程序對象的標準方法，現簡述如下：

1、盡可能避免將私密的對象引用暴露給用戶，如重要的關鍵字或文件名。

2、運用一種“可接受的良好方法”，詳細地驗證任何私密的對象引用。決定準許用戶訪問哪些文件，并僅授與這些用戶訪問這些文件的權力。

3、對所有引用的對象都要進行驗證。

OWASP還提供了第三個要點的一個例子。在此，黑客可以將電子商務網站的購物車ID參數改為任何值： 

int cartID = Integer.parseInt( request.getParameter( "cartID" ) );  
 
String query = "SELECT * FROM table WHERE cartID=" + cartID; 

要想防止受到這種攻擊，就只能允許獲得授權的記錄可以顯示： 

int cartID = Integer.parseInt( request.getParameter( "cartID" ) );  
 
User user = (User)request.getSession().getAttribute( "user" );  
 
String query = "SELECT * FROM table WHERE  
 
cartID=" + cartID + "AND userID=" + user.getID(); 

直接對象引用的另外一種選擇是每個用戶或會話都使用非直接的對象引用。

在前面那個關于信用卡的例子中，用戶需要從兩個卡中選擇一個信用卡，這會暴露對信用卡數據庫的直接引用。一個更好的方法是將這兩個信用卡的記錄存儲到一個針對此用戶的特定陣列中。關于信用卡的選擇，其代碼類似于下面的內容： 

<select name=" choosecreditcard"> 
 
<option value="1"> 
 
XXXXXXXXXXXX6902  
 
</option> 
 
<option value="2"> 
 
XXXXXXXXXXXX5586  
 
</option> 
 
</select> 

在這種方法中，僅有對此用戶陣列的一個直接引用，它僅包含此用戶的數據。將選項的值改為大于2的任何值不會導致其他用戶的信用卡細節被利用。然后，應用程序將把用戶的特定的非直接對象引用（選項值為1或2）映射回底層的數據庫關鍵字（前面例子中的56和88）

對不安全的直接對象引用的測試

不幸的是，漏洞掃描器在發現不安全的直接對象引用漏洞方面并不是很高效，所以最佳的選擇是：

1、仔細檢查代碼，確認是否有重要的參數易于遭到利用和操縱。

2、經常實施專業的滲透測試。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]