[toc] # 邏輯漏洞 可安裝webbug3.0系統模擬攻擊 ## 邏輯漏洞基礎信息 之所以稱為邏輯漏洞，是因為代碼之后是人的邏輯，人更容易犯錯，是編寫完程序后隨著人的思維邏輯產生的不足。 sql注入、xss等漏洞可以通過安全框架等避免，這種攻擊流量非法，對原始程序進行了破壞，防火墻可以檢測 而邏輯漏洞是通過合法合理的方式達到破壞，分別為不安全對象引用和功能級別訪問控制缺失。 * 不安全對象引用，指的是平行權限的訪問控制缺失， 比方說，A 和 B 兩個同為一個網站的普通用戶，他們之間的個人資料是相互保密的，A用戶的個人資料可以被 B 用戶利用程序訪問控制的缺失惡意查看，由于 A 用戶和 B用戶之間是一個同級的賬號，因此稱為平行權限的訪問控制缺失。 * 功能級別訪問控制缺失，指的是垂直權限的訪問控制缺失 比方說，A 賬號為普通賬號、B 賬號為管理員賬號，B 賬號的管理頁面時必須是以管理員權限登錄后方可查看，但 A 賬號可通過直接輸入管理頁面 URL 的方式繞過管理員登錄限制查看管理頁面，由于 A用戶和 B用戶的權限是垂直關系，因此稱為垂直權限的訪問控制缺失。 該類型屬于業務設計缺陷的安全問題，因此傳統的掃描器是無法發現的，只能通過手工的滲透測試去進行檢查。在金融平臺中以平行權限的訪問控制缺失較為常見。 建議在烏云鏡像站多看看別人挖掘邏輯漏洞的過程 ### 常見的邏輯漏洞： 1. 越權修改 2. 越權查詢 3. 驗證碼回傳 4. 未進行登陸憑證驗證 5. 訂單金額任意修改 6. 密碼重置 7. 突破限制等 ### 挖掘邏輯漏洞的環節： 把握住傳參就能把握住邏輯漏洞的命脈 1. 確定業務流程 2. 尋找流程中可以被操控的環節 3. 分析可被操控環節中可能產生的邏輯問題 4. 嘗試修改參數觸發邏輯問題 ## 1??越權訪問 越權訪問（Broken Access Control，簡稱BAC）是Web應用程序中一種常見的漏洞，在實際的代碼審計中，這種漏洞往往很難通過工具進行自動化監測，因此在實際應用中危害很大。 ### 原理說明 如果使用A用戶的權限去操作B用戶的數據，A的權限小于B的權限，如果能夠成功操作，則稱之為越權操作。 越權漏洞形成的原因是后臺使用了不合理的權限校驗規則導致的。 一般越權漏洞容易出現在權限頁面（需要登錄的頁面）增、刪、改、查的的地方，當用戶對權限頁面內的信息進行這些操作時，后臺需要對當前用戶的權限進行校驗，看其是否具備操作的權限，從而給出響應，而如果校驗的規則過于簡單則容易出現越權漏洞。 如果有waf的時候,優先考慮越權漏洞和邏輯漏洞 ### 1、水平越權： **權限類型不變，權限ID改變** 水平越權訪問是一種【基于數據的訪問控制】設計缺陷引起的漏洞。由于服務器端在接收到請求數據進行操作時沒有判斷數據的所屬人/所屬部門而導致的越權數據訪問漏洞。? 水平越權測試方法：主要通過看看能否通過A用戶操作影響到B用戶 ### 2、垂直越權： **權限ID不變，權限類型改變** 垂直越權是一種【基于URL的訪問控制】設計缺陷引起的漏洞，又叫做權限提升攻擊。 垂直越權測試思路：看看低權限用戶是否能越權使用高權限用戶的功能，比如普通用戶可以使用管理員的功能。 先抓包高權限用戶的某一操作，在抓包低權限用戶包，將低權限用戶cookie等復制到高權限包中，看能否完成同樣的操作 ### 真實案例：XX網參數越權 --- 問題描述：測試過程中發現，用戶在“地址管理”功能模塊可越權查看任意收貨信息，造成用戶敏感信息泄露。 1、在地址管理中，選擇“修改”，此時用抓包工具截斷GET請求： ``` #抓包數據鏈接為： http://www.XXXX.cn/index.php?app=treasure&mod=Order&act=findId&address_id=1111 #將address_id參數值替換為任意數值如2222： #提交后發現返回了對應用戶的收貨信息 ``` ### 越權漏洞突破思路 1. 一般管理頁面可能存在越權漏洞 如果是白盒測試的話 找到admin相關 需要管理員賬號才可以訪問的文件 針對于前端繞過 訪問該目錄，可能會有一個js攔截，我們利用瀏覽器隱私安全性設置找到javascrip禁用 添加網站，再次進入可能會成功 針對于后端繞過 對于沒有判斷登錄狀態refer或者判斷不標準，抓包修改為合法的refer就可以繞過 2. 有的對于用戶管理的地方可能有，例如更改用戶收貨地址等 先用自己的賬號登錄，之后抓包，將id等改變一下，查看返回值驗證 3. 有時候通過將cookie修改為他人的，也可以實現越權 4. 參數也可能有越權漏洞，例如訂單編號等等 5. 注冊過程中，輸入已經注冊過的郵箱，在相應信息中可能有返回信息的 6. 還有修改密碼如果沒有對手機號位數限制（數字位數，或者空格等特殊符號）也可能有漏洞 小結：在找越權的時候，對參數要有很強的關注，可以每一個都試一試 ## 2??交易支付中的邏輯問題： --- ### 支付的邏輯漏洞的一般思路 一種是少充多得，比如充值100元時通過篡改金額改成10元，最終充值完畢后賬戶變成了100元，而實際付款卻只有10元； 一種是繞過活動頁金額限制，比如很多公司做活動強制用戶充值金額不能低于10000，而通過攔截修改金額，可以充值任意金額。 一般購物流程： 1. 挑選商品加入購物車 2. 確認購物車信息 3. 輸入物流及收貨人信息 4. 確認訂單進入支付環節 5. 交易成功等待發貨 購物流程中可能的邏輯問題： 1. 加入購物車時是否可以修改購買數量為負數,商品價格是否可以修改. 2. 確認購物車信息時是否可以修改商品數量為負數,是否存在折扣限制突破問題,是否可以修改商品總金額. 3. 輸入物流信息時是否可以控制運費,如果可以,嘗試修改為負數. 4. 確認訂單后跳轉支付接口時是否可以修改支付金額,可否不支付直接跳轉到交易成功環節. ### 預防思路： --- 增加多重檢驗，訂單較大時增加人工審核。 ### 實案例：信用卡還款服務費被繞過 --- 問題分析：測試發現，微錢包信用卡還款功能處存在服務費可繞過漏洞，測試過程如下： 1、選擇信用卡還款功能，填寫相關還款數值后，截斷信用卡還款GET請求，將f參數值修改為1： 2、提交修改后的請求，頁面返回成功： ## 3??密碼修改邏輯漏洞： 重置密碼對一個系統來說是非常重要的存在，所以存在的問題也是非常致命。 1. 用戶在重置密碼頁面，通過修改用戶ID對所改用戶密碼進行重置； 2. 對密碼重置頁面驗證碼繞過，然后爆破進行等。 ### 密碼修改邏輯漏洞驗證  * 首先走一遍正常的密碼修改流程,把過程中所有環節的數據包全部保存. * 分析流程中哪些步驟使用了哪些身份認證信息,使用了哪些認證方法. * 分析哪個步驟是可以跳過,或者可以直接訪問某個步驟. * 分析每個認證方法是否存在缺陷,可否越權? * 首先嘗試正常密碼找回流程,選擇不同找回方式,如郵箱,手機,密碼提示問題等. * 分析各種找回機制所采用的驗證手段,如驗證碼的有效期,有效次數,生成規律,是否與用戶信息相關聯等. * 抓取修改密碼步驟的所有數據包,嘗試修改關鍵信息,如用戶名,用戶ID,郵箱地址,手機號碼等。詳細看以下案例： >http://www.wooyun.org/bugs/wooyun-2010-011435 >http://www.wooyun.org/bugs/wooyun-2010-08573 >http://www.wooyun.org/bugs/wooyun-2010-012365 >http://www.wooyun.org/bugs/wooyun-2010-021818 >http://www.wooyun.org/bugs/wooyun-2010-020625 >http://www.wooyun.org/bugs/wooyun-2010-020588 >http://www.wooyun.org/bugs/wooyun-2010-019769 >http://www.wooyun.org/bugs/wooyun-2010-018722 ### 預防思路： 系統后臺在重置密碼頁面驗證是否為本用戶等。 ## 4??驗證碼回傳： ### 漏洞原因 這個漏洞主要是發生在前端驗證處，只要攔截數據包就可以獲取敏感信息，并且經常發生的位置在：賬號密碼找回、賬號注冊、支付訂單等。驗證碼主要發送途徑郵箱郵件 、手機短信。黑客只需要抓取Response數據包便知道驗證碼是多少。 ### 預防思路： response數據內不包含驗證碼，驗證方式主要采取后端驗證，但是缺點是服務器的運算壓力也會隨之增加；要進行前端驗證的話使用加密進行。 ## 5??接口無限制枚舉： 有些關鍵性的接口因為沒有做驗證或者其它預防機制，容易遭到枚舉攻擊。 ### 真實案例：用戶激活郵件炸彈攻擊 問題描述：測試發現，用戶使用郵箱注冊時，發送激活郵件功能可進行郵件炸彈攻擊。測試過程如下： 1. 用戶在激活賬號過程中選擇“重新發送”： 2. 將GET請求中的uid參數值為其他uid（需要此uid的用戶也使用郵箱注冊）： 3. 重放此數據包，可形成郵件炸彈攻擊，響應包中提示發送成功： ### 防范措施： 1. 使用最小權限原則對用戶進行賦權; 2. 永遠不要相信來自用戶的輸入，使用合理（嚴格）的權限校驗規則; 3. 使用后臺登錄態作為條件進行權限判斷,別動不動就瞎用前端傳進來的條件; 4. cookie中設定多個驗證，比如自如APP的cookie中，需要sign和ssid兩個參數配對，才能返回數據。 5. 用戶的cookie數據加密應嚴格使用標準加密算法，并注意密鑰管理。 6. 用戶的cookie的生成過程中最好帶入用戶的密碼，一旦密碼改變，cookie的值也會改變。 7. cookie中設定session參數，以防cookie可以長時間生效。 ## 6 邏輯漏洞導致的問題 ### 業務安全問題 一些生產環境中可能出現的實際問題，我認為這不只是滲透測試工程師需要針對的，也是一些開發人員需要意識到的 ### 賬戶安全 盜號、撞庫等身份盜用問題 “撞庫”攻擊的形式 * 嘗試登錄大量【用戶名+密碼】組合 * 利用已泄露的多家網站用戶數據庫 * “盜號”產生的風險 * 用戶隱私受影響 * 賬戶資金受影響 * 企業投訴和賠付率上升 ### 資源濫用 1. 刷單/惡意下單 供應商刷單賺取信用 競爭對手互相下單 報復性下單 2. 控制庫存影響正常銷售 自動加購物車，自動下單 購物車過期后，重復上一步驟 正常用戶不能購買 企業商品無法售出 3. 惡意調用短信發送接口 封裝多個網站短信發送接口為一個API 向指定手機發送短信炸彈，強制對方關機 企業遭受客戶投訴導致短信通道被迫關停 4. 注冊檢查薄弱被利用接口 利用簡單的注冊判斷接口，檢查全國手機號是否在網站注冊 放大這個請求，結果是災難……為盲目“撞庫”提前篩選用戶名 5. 惡意注冊產生“馬甲”用戶 搶占正常用戶資源 影響企業營銷效果 產生虛假數據 隱藏的“炸彈”