《白帽子講Web安全》10-訪問控制

第10章 訪問控制

對於權限的合理分配，一直時安全設計中的核心問題。

10.1 What Can I Do?

1. 認證解決了“Who am I?”的問題，而授權解決了“What Can I Do?”的問題。
2. 某個主體（subject）對某個客體（object）需要實施某種操作（operation），而系統對這種操作的限制就是權限控制。
   
   • 網絡中通過路由設備或者防火牆建立基於IP的訪問控制
   • 操作系統中對文件的訪問控制
3. Web應用中，根據訪問客體的不同，常見的訪問控制可以分爲：
   
   • 基於URL的訪問控制
   • 基於方法（method）的訪問控制
   • 基於數據的訪問控制
4. 當訪問控制存在缺陷時的後果。
   
   • 正常情況下，管理後臺的頁面應該只有管理員才能夠訪問。
   • 系統未對用戶訪問權限進行控制，導致任意用戶只要構造出了正確的URL，就能夠訪問到這些頁面。
5. 把需要保護的頁面“藏”起來，並不是解決問題的辦法。
   
   • 攻擊者慣用的伎倆時使用一部包含了很多後臺路徑的字典，把這些“藏”起來的頁面掃出來。

10.2 垂直權限管理

1. “基於角色的訪問控制（Role-Based Access Control），簡稱RBAC。

用戶 - 角色 - 權限

RBAC事先會在系統中定義出不同的角色，不同的角色擁有不同的權限，一個角色實際上就是一個權限的集合。

1. Spring Security的授權功能
   
   • 基於URL的訪問控制
   • 基於method的訪問控制
   • 基於表達式的訪問控制
2. 在配置權限時，應該使用“最小權限”原則，並使用“默認拒絕”的策略，只對有需要的主體單獨配置“允許”的策略。這在很多時候能夠避免發生“越權訪問”。

10.3 水平權限管理

1. 在正常情況下，應該只有用戶自己才能訪問自己的私有數據。
   
   • 優酷網用戶越權訪問問題：用戶可以查看他人的來往信件。
   • 來伊份用戶可以查看其他用戶的個人姓名、地址等隱私信息。
2. 由於水平權限管理是系統缺乏一個數據級的訪問控制所造成的，因此水平權限管理又可以稱之爲“基於數據的訪問控制”。
3. 目前數據級權限管理並沒有很通用的解決方案，一般是具體問題具體解決。
   
   • 一個簡單的數據級訪問控制，可以考慮使用“用戶組（Group）”的概念。
   • 可以考慮實現一個規則引擎，將訪問控制的規則寫在配置文件中，通過規則引擎對數據的訪問進行控制。

10.4 OAuth簡介

1. OAuth是一個在不提供用戶名和密碼的情況下，授權第三方應用訪問Web資源的安全協議。
2. OpenID解決的是認證問題，OAuth則更注重授權。
3. 常見的應用OAuth的場景，一般是某個網站想要獲取一個用戶在第三方網站中的某些資源或服務。
4. 在OAuth 1.0中，涉及3個角色：
   
   • Consumer：消費方（CLient）
   • Service Provider：服務提供方（Server）
   • User：用戶（Resource Owner）
5. OAuth舉例
   
   • Request Token只能用於獲取用戶的授權
   • Access Token才能用戶訪問用戶的資源
6. 使用第三方實現的OAuth庫也是一個比較好的選擇。
   
   • OAuth涉及諸多加密算法、僞隨機算法等容易被程序員誤用的地方。
7. 常見的需要用到OAuth的地方有桌面應用、手機設備、Web應用。
   
   • OAuth 1.0只提供了統一的接口
   • OAuth 1.0的應用架構在擴展性方面也存在一些問題，當用戶請求數龐大時，可能會遇到一些性能瓶頸。
   • OAuth 2.0改善了上述情況。

10.5 小結

1. 訪問控制解決了“What Can I Do?”的問題
2. 垂直權限管理——基於角色的訪問控制
3. 水平權限管理——基於數據的訪問控制
4. 訪問控制與業務需求息息相關，並非一個單純的安全問題。
5. 無論選擇哪種訪問控制方式，在設計方案是都應該滿足“最小權限原則”。這是權限管理的黃金法則