Authorization 授權的資訊安全設計原則、測試、個案與實作
Authorization 主要是在經過認證完之後，跟對該使用者對於系統資源存取的”授權”，
因此怎樣的權限可以存取哪些資料就是 Authorization的範疇。基本要回答的問題是
- 使用者可以使用這個功能嗎?
- 進一步是問這個功能針對該使用者存取的範圍是否應該限制?
我們將討論安全設計的準則、新聞個案討論、測試的方法與實務設計的建議。
基本安全設計準則
基本安全設計的準則有
- 所有的頁面應該都需要經過授權才能存取
- 所有的功能或是頁面必須確認資訊的內容是否經過授權
- 伺服器與資料庫等權限的設定
所有的頁面應該都需要經過授權才能存取
針對網頁來說，最著名的攻擊方式就是 Forced Browsing 或是 Directory Traversal
新聞個案 Directory Traversal
https://cwe.mitre.org/data/definitions/548.html
http://www.securityfocus.com/archive/1/506000/100/0/threaded
駭客有可能透過 ULR 參數的不同，間接讀取到不屬於自己的相關資料。
http://localhost/cuteflow/pages/edituser.php?userid=1&language=pt&sortby=strLastName&sortdir=ASC&start=1
前端與後端都要確認權限的存取
為什麼前端使用者輸入時就已經檢查過，後端伺服器或是資料庫還要額外檢查呢?
主要是因為駭客可以透過 FireFox Add Tamper Data 這樣的工具跳過前端的檢查，而將資料直接輸入到後端伺服器
PayPal 新聞案例
http://letsearndollar.blogspot.com/2009/07/change-any-paypal-price-with-data.html
例如 PayPal 在結帳時的運費與稅率，可以透過 Tamper Data 的方式被修改為 “0”
安全設計提醒
- 所有的頁面應該都需要經過授權才能存取
- 所有的功能或是頁面必須確認資訊的內容是否經過授權 (避免 Directory listing or traversal)
- 除了前端檢查輸入的資料之外，後端資料庫與伺服器也要相對的檢查
- 伺服器與資料庫等權限的設定
另外 OWASP 針對 Access Control 的部分建議如下
- Code to the activity, not the role
- Centralize access control logic
- Design access control as a filter
- Deny by default, fail securely
- Build centralized access control mechanism
- Apply same core logic to presentation and server-side access control decisions
- Determine access control through Server-side trusted data