邏輯漏洞的原理及分析
前言
之前的文章都是寫的SQL注入，命令執行，文件上傳等一步到位的高危漏洞原理及防禦，接下來說一說邏輯漏洞，因為現在工具的大量使用，之前的那些主流漏洞，很難被輕易利用了，邏輯漏洞不一樣，工具不會思考，所以應用程式有邏輯缺陷，工具很難發現，需要人為去挖掘，接下來就簡單說一說，如何來進行邏輯漏洞的挖掘。
邏輯漏洞本質
web應用程式中的邏輯漏洞各不相同，有的很明顯，有的很微妙。與SQL注入和跨站不同，邏輯漏洞沒有共有的「簽名」，定義特性是指應用程式執行的邏輯存在某種缺陷。大部分邏輯缺陷表現為開發者在思考過程中做出的特殊假設存在明顯或隱含的錯誤，通俗點來說，有的開發者會這樣認為，如果發生A，就會出現B，因此我執行C。沒有考慮如果發生X會怎麼樣，這種錯誤的假設會造成許多安全漏洞。邏輯漏洞是多樣性的，挖掘它們需要從不同的角度思考問題，設法了解設計者和開發者做出的各種假設，然後考慮如何攻擊。
常見的邏輯漏洞
一般哪些地方容易報出邏輯漏洞呢，比如，密碼找回、交易支付、密碼修改、突破限制等。
密碼找回中的邏輯問題
關於密碼找回的邏輯問題，我畫了一個思維導圖，把可能出現邏輯缺陷都寫出來了。如下圖
比如第四條，如果驗證碼沒有銷毀，或者是驗證碼沒有刷新，我們是不是可以嘗試進行暴力破解。再比如第六條，如果沒有進行非空判斷，那驗證也是可以繞過。
密碼修改中的邏輯問題
密碼修改過程中，可能存在的邏輯問題，我也以畫思維導圖為例，如下圖
交易支付中的邏輯問題
現在電商這麼發達，如果你不想去淘寶開店，自己搭建一個，那就要分析可能存在的邏輯問題了。下面我就以電商購買商品的過程為例，分析可能存在的邏輯問題，這次以流程圖的方式。
- 加入購物車時，抓包嘗試修改購買數量為負數，試一試商品價格能否修改。
- 確認購物車消息時，嘗試修改金額，如果購買多件打折，嘗試能不能突破這個邏輯，比如先加入購物車，再把多餘的移除，看有沒有效果。
- 物流這裡嘗試能否修改運費，或改為負數，雖然現在大部分都包郵，萬一有漏網之魚了。
- 確認訂單跳轉支付介面時，看能不能修改金額，嘗試能不能跳過支付，直接跳到支付成功的頁面。
還有一些其他的就不依次分析了。
修復建議
- 確保將應用程式各方面的設計資訊都詳細的記錄在文檔中，方便其他人了解設計者做出的每個假設。
- 要求源程式碼提供清楚的注釋，包括每個程式碼的組件的用途和預計用法以及每個組件對它無法直接控制的內容做出的假設。
- 根據會話確定用戶的身份和許可權，不要根據請求的其他特性對用戶的許可權做出假設。
小結
發掘邏輯漏洞時，要對程式進行系統性的探查，也要從不同的角度思考問題。除了這些，挖掘邏輯漏洞的最大挑戰是如何深入的了解開發者的思維方式，需要了解到他們想要達到什麼目的，可能做出什麼假設，可能採用哪些捷徑，將會犯什麼錯誤。想像一下，如果程式完工的最後，還在擔心功能，而不是安全，要加入新功能，這樣的情況下，開發者可能犯什麼錯誤等等。
