公司專案重構 Web安全訪問控制

如時間有限，可直接閱讀防範手段一節。

今年開始公司準備對專案做部分重構，其中安全性問題首當其衝，除了已知的問題外，還需要發散思維，盡可能找出更多的潛在問題。期間發現一本非常好的書《白帽子講web安全》，感謝吳翰清大佬，讀完本書讓我對web安全有了更深刻的理解，強烈推薦大家閱讀。

我打算記錄下整個安全性重構的過程，相關知識點大部分會摘抄自《白帽子講web安全》，因為總結的很到位了，最後記錄下公司內採用的防範手段（敏感資訊不會書寫）。

許可權控制（或者說訪問控制）抽象地說：就是某個主體（subject）對某個客體（object）需要實施某種操作（operation），而系統對這種操作的限制就是許可權控制

在web應用中，根據訪問客體的不同，常見的訪問控制可以分為：

根據控制方式的不同，又可以分為：

基於url和基於方法的訪問控制都是很好實現的，主流框架spring security和shiro都提供了解決方案，這兩種訪問控制方式我們稱為」垂直許可權管理「，不同角色的許可權有高低之分，高許可權角色可以訪問低許可權的資源，反之則不行。

基於資料的訪問控制，我們稱為」水平許可權管理「，針對同一角色的使用者，也需要控制他們只能訪問屬於自己的私有資料，需要將資料與使用者繫結。避免在資料上的訪問越權。

未做訪問控制的漏洞

在正常情況下，管理員後台的頁面應該只有管理員才能訪問，但有些系統並未對使用者的訪問進行控制，導致任意使用者只要能構造出正確的url，就可以訪問這些頁面。有些系統採用的做法是在頁面上隱藏入口，但是把需要保護的頁面」隱藏「起來，並不是安全的解決方案。

攻擊者會使用一部包含許多後台路徑的字典進行掃瞄，比如大部分後台管理的路徑都包含admin。除了攻擊者，內部員工也可能會造成風險，因為他們知道哪些url是沒做許可權控制的。

使用者對資料越權訪問的隱患

id通常是記錄的唯一標識，那麼在url上修改引數id的值是否能訪問其他記錄呢，通過遞增或遞減id是否可以遍歷出庫里的所有資訊呢？

假如個人資訊頁面的路徑為：user/info?id=234524，如果後台程式是接收id引數到庫里檢索的，並且沒有判斷該記錄是否屬於本人，那麼是可以看到其他使用者資訊的。

訪問控制實際上是建立使用者與許可權之間的對應關係，現在廣泛使用的是」基於角色的訪問控制（role-based access control）「，簡稱rbac。

rbac大概流程：系統中會定義不同許可權（資源的標識，常用是訪問url），角色繫結不同的許可權集合，所有使用者都會被分配不同的角色（可多個）。在驗證許可權時，只需要驗證使用者所屬的角色或其角色所具備的許可權。

目前的安全框架，只能做到不同角色之間的許可權控制，而水平許可權管理的問題沒有好的解決方案，因為相對於垂直許可權管理來說，水平許可權問題出在同一角色上，系統只驗證了能訪問資料的角色，既沒有對角色內的使用者做細分，也沒有對資料的子集做細分，因此缺乏乙個使用者到資料之間的對應關係。

比如使用者a和使用者b都屬於同一角色，但是使用者a和使用者b各自擁有一些私有的資料（比如個人資訊），在正常情況下，他們應該只能訪問自己的私有資料。但是在rbac這種」基於角色的訪問控制「模型下，系統只會驗證他們是否具備指定角色，而不會判斷資料屬於誰，因此就會發生越權訪問。

但是很遺憾，對於資料的訪問控制，通常與業務結合很緊密，有些可能需要控制有些可能不需要，所以很難統一做控制。

書中提到了建議方案：乙個簡單的資料訪問許可權，可以使用」使用者組（group）「的概念，比如乙個使用者組的資料只屬於該組內的成員，只有同一使用者組的成員才能對這些資料操作。

當然了，還需要開發人員做好基本的安全校驗，比如查詢自身資料時，盡量從session中獲取使用者id，而不是頁面傳入；並且查詢或運算元據前，先判斷是否為本人建立的資料（看業務要求）。

自增id的資料會非常好猜測，遞增或遞減即可。為此我們需要避免直接使用單錶的自增id作為引數來回傳輸，可以採⽤其他策略生成id:

另外，我們在與第三⽅對接資料時，可以採取加密id的⽅式，或使⽤其他⾮敏感資料，⽐如⽤戶名、部⻔編碼等可公開且不重複的字段。

暫時就寫到這裡，如有變化，會及時更新的。如有錯誤，請大家及時提出。

再次感謝吳翰清大佬！

公司專案重構 Web安全 訪問控制