原文：
水平許可權漏洞一般出現在乙個使用者物件關聯多個其他物件（訂單、位址等）、並且要實現對關聯物件的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來吧。
另外的方法：
1、可對id加密
2、使用guid
3、每乙個資訊增加乙個發布人的字段，修改的人必須與發布的人為同乙個人才可以訪問
許可權漏洞 水平許可權漏洞 垂直許可權漏洞
水平許可權漏洞是指web應用程式接收到使用者請求時，沒有判斷資料的所屬人，或者在判斷資料所屬人時是從使用者提交的引數中獲取了userid，導致攻擊者可以自行修改userid修改不屬於自己的資料。漏洞示例 getaddress?id 1 如上，攻擊者修改 addressid即可得到他人的address...
httpoxy 漏洞預警及修復方案
php go python等開啟cgi client 模式的指令碼語言 language 環境依賴 在cgi rfc 3875 的模式的時候，server 會把請求中的 header，加上 http 字首，註冊為環境變數，且重名變數會被覆蓋汙染，若該變數被指令碼呼叫，即可利用，該漏洞在15年前在lw...
Linux Bash嚴重漏洞緊急修復方案
今天剛剛爆出bash安全漏洞，bash存在乙個安全的漏洞，該漏洞直接影響基於unix的系統 如linux os x 等 該漏洞將導致遠端 者在受影響的系統上執行任意 已確認被成功利用的軟體及系統 所有安裝gnu bash 版本小於或者等於4.3的linux作業系統。漏洞描述 該漏洞源於你呼叫的bas...