數據越權訪問，誰之錯?

　　在OWASP Top 10中，有一類漏洞的大類，稱之為越權訪問(Broken Access Control, 簡稱BAC)。顧名思義，這類漏洞是指應用在檢查授權(Authorization)時存在紕漏，使得攻擊者可以利用一些方式繞過權限檢查，訪問或者操作到原本無權訪問的代碼。在實際的代碼安全審查中，這類漏洞往往很難通過工具進行自動化檢測，因此在實際應用中危害很大。經驗證明，解決這類問題，往往需要從系統設計上著手。

　　猛買網張磊：基于又拍云存儲解決靜態文件存儲問題

　　我們以一個實際存在過的BAC漏洞為例，來看看這種問題發生的根源及解決辦法是什么。

　　國內互聯網漏洞報告平臺烏云在去年年底報告了一個存在于國內某知名電子商務網站的BAC漏洞wooyun-2011-03271(http://www.wooyun.org/bugs/wooyun-2011-03271)。該網站存在一個公開的HTTP接口myaddress.aspx。此接口根據接收的參數addressid來返回json格式的消費者收貨地址數據，然后在前端頁面上由JS解析進行展示。這是一個很多同類網站都會用到的一個普通功能。

　　在烏云的漏洞報告中，我們看到，白帽子利用傳入參數的可猜測性(使用整形數據做記錄id)，直接變更輸入的addressid參數，就可以拿到他人隱私信息。這是一個典型的BAC問題。修復也非常簡單，只要在服務端對請求的數據和當前用戶身份做一個校驗檢查即可。但是在這類應用中，諸如此類的數據如此之多，從地址數據，到訂單信息、支付信息等等，無一不需要小心處理。當業務復雜到一定程度之后，沒有誰能夠保證這些數據的訪問都經過了嚴格的權限檢查。所以出現BAC問題，似乎是難以避免的。

　　讓我們從設計的角度重溫一下這個用例中的一些普遍特征。

　　對于收貨地址而言，在這類B2C商務平臺上應該存在幾類不同的訪問場景：

　　對于平臺運營商來說，需要有權限對這些數據進行讀取操作。

　　對于在平臺上開展銷售的商家來說，一旦與該用戶產生了直接的交易，那么也應該對這些數據有權進行操作(實際上地址數據會在產生訂單時發生克隆，我們簡化這個過程，視之為引用關系)。

　　對于消費者本身，應該有權對這些數據進行操作。

　　那么最基本的，針對這些場景，我們需要對目標數據的訪問進行不同邏輯的權限檢查。

　　如果是平臺運營系統請求數據，那么不需要進行權限校驗。

　　如果是平臺商家用戶請求數據，那么應該檢查該數據的擁有者，即消費者，是否授權該商家訪問其地址信息(判斷依據為檢查是否產生交易) 。

　　對于消費者本身，需要檢查目標數據的擁有者與請求方是否同一用戶。

　　這三類場景需要的檢查邏輯各不相同，那么在后端，我們需要什么樣的API或者服務(Service)來為前端的這三種場景提供數據呢?

　　通常的系統中都會存在類似GetAddressById這樣的API或者服務，來為前端系統服務。那么接下來前端系統需要根據自身的場景，來實現各自的校驗邏輯。但是，這樣合理嗎?由于這些API的粒度是如此之小，任何一個開發人員，在實現任何一個業務場景時都可能會使用到。這些使用到的地方，如何保證都經過嚴格的權限檢查呢?

　　可能AOP是一種解決問題的方式，但是實際實現中，你會發現，很難針對不同的使用場景而提供一致的權限校驗方式。姑且不論性能高低，僅就用戶身份的確認這一點，就很難在統一的代碼中去適應不同的場景。

　　那么我們就需要重新來審視GetAddressById這種API了。對于平臺運營商系統的使用場景，這個API沒有任何問題。但是對于平臺商家后臺和消費者系統，是否需要類似于GetAddressByIdAndMerchantId和GetMyAddressById這種API呢?

　　僅僅增加了不同粒度的后端API，這并不能保證從此可以高枕無憂了。對前端開發者來說，如果這3個API都可見可用，那么很難保證不會被使用在不恰當的場景中。

　　一個在實際應用中被采用的解決方案是，把這3個API封裝到不同的服務(Service)或者包(Package)中，并在不同的項目中設置僅對自己的場景可見。這樣在每個應用中，也只能使用符合自己的業務場景安全要求的后端API/Service。

　　現實中的情況可能復雜很多，貫穿業務系統前后端的ACL(訪問控制列表)在實現上會非常繁瑣而且成本較高，也可能并不適用于每個應用場景。但是分清楚數據的安全域劃分，根據不同的場景設計符合要求的后端API/Service，同時對后端API/Service根據不同的安全域進行隔離，這是非常實用的一種思路。

　　好的后端API/Service設計，會讓開發者即使并不清楚相關的安全考量和安全開發知識，依然能夠開發出符合授權標準的應用。這也是安全架構的重要組成部分。

原文轉自：http://www.kjueaiud.com