水平權限漏洞一般出現在一個用戶對象關聯多個其他對象（訂單、地址等）、並且要實現對關聯對象的CRUD的時候。開發容易習慣性的在生成CRUD表單（或AJAX請求）的時候根據認證過的用戶身份來找出其有權限的被操作對象id，提供入口，然后讓用戶提交請求，並根據這個id來操作相關對象。在處理CRUD請求時，往往默認只有有權限的用戶才能得到入口，進而才能操作相關對象，因此就不再校驗權限了。可悲劇的是大多數對象的ID都被設置為自增整型，所以攻擊者只要對相關id加1、減1、直至遍歷，就可以操作其他用戶所關聯的對象了。
水平權限漏洞的原理看似簡單，但他和開發的思維、編碼習慣剛好相反，因此會經常冒出來。尤其是WAP和AJAX接口，開發者往往不把這些接口當作HTTP請求看，增加了很多其實不存在的有利於安全假設條件，從而導致更加忽視對權限的鑒別。
因為這類關聯對象的操作都和業務相關，且接口獨立，所以很難實現通用的預防或解決方案，這也是這類漏洞讓人頭疼的原因之一。今天在修復一個水平權限漏洞時，給開發同學介紹了下水平權限漏洞的修復方案，而開發同學又提出了一個我之前沒想過的方法，因此決定一起整理出來。
漏洞示例：
getAddress.do?addressId=12345
攻擊者修改addressId即可得到他人的address信息。
修復方案0：
先看一個有問題的方案：將addressid改成一個具有一定長度的隨機字符串，如5d41402abc4b2a76b9719d911017c592，認為只有有權限的人才能得到這個入口，而且不能通過加1、減1的方式預測別人的入口，因此不再做進一步的權限檢查（很多初級的招聘頁面都是以這種方式來管理簡歷的）。這個方案看上去沒有問題，可是和國內的環境結合起來就會悲劇——至少我遇到過的，搜狗瀏覽器會把用戶發送的請求上傳到服務器上，作為其搜索引擎爬蟲的爬取源，這樣爬蟲就會通告查詢操作得到相關的對象信息，並展示在搜索引擎上，如果對象信息包含敏感內容，則產生隱私泄露的安全事件。
修復方案1：
這個是最直接有效的修復方案：在web層的邏輯中做鑒權，檢查提交CRUD請求的操作者（通過session信息得到）與目標對象的權限所有者（查數據庫）是否一致，如果不一致則阻斷。這個方案實現成本低、能確保漏洞的修復質量，缺點是增加了一次查庫操作。我之前一直用這種方案來對已發生的水平權限漏洞做緊急修復。
修復方案2：
我認為最正規的方案：把權限的控制轉移到數據接口層中，避免出現select/update/delete ... where addressID=#addressID#的SQL語句，使用selectt/update/delete... where addressID=#addressID# and ownerId=#userId#來代替，要求web層在調用數據接口層的接口時額外提供userid，而這個userid在web層看來只能通過seesion來取到。這樣在面對水平權限攻擊時，web層的開發者不用額外花精力去注意鑒權的事情，也不需要增加一個SQL來專門判斷權限——如果權限不對的話，那個and條件就滿足不了，SQL自然就找不到相關對象去操作。而且這個方案對於一個接口多個地方使用的情況也比較有利，不需要每個地方都鑒權了。但這個方案的缺陷在於實現起來要改動底層的設計，所以不適合作為修復方案，更適合作為統一的控制方案在最開始設計時就注意這方面的問題。
修復方案3：
今天開發同學提到一種我之前沒想到過的方式，實際上是對方案1的修改：在生成表單時，增加一個token參數，而token=md5(addressId+sessionId+key)；在處理請求時，用addressId、sessionId和key來驗證token。這樣的方案實現起來很簡單，又不增加額外的SQL查詢開銷，看起來比方案1更好。可我之前沒有想到過這種方案，乍一看又是把鑒權和操作這一串同步的操作異步化了（實際上是在生成表單的時候鑒權並生成token，然后在操作時只驗證token而不鑒權），所以一時還拿不准這樣會不會有啥問題～不過我是想了半天也找不到漏洞哈～
修復方案4：
把這種屬主、權限、對象、操作的場景抽象成一個統一的框架，在框架內一個地方實現權限的管理和檢查。當然這個說起來有點扯淡了，在產品設計階段是不是有人願意花大成本來設計相關框架呢？如果最開始沒有框架，那么什么時候願意花更大的成本去遷移呢？我想最終還是會按方案1、2、3來吧。
原文：http://hi.baidu.com/kussa/item/a85912058445c7dcdce5b01d
另外的方法：
1、可對ID加密
2、使用GUID
3、每一個信息增加一個發布人的字段，修改的人必須與發布的人為同一個人才可以訪問