所有應用程序都是通過邏輯實現各種豐富多彩的功能的，要實現這些功能，必須掌握大量的技巧并進行周密的安排。但是，有很多情況這些功能邏輯存在缺陷，比如程序員的安全意識，比如考慮問題不周全等。即使是最簡單的web應用程序，每個階段都會執行大量的邏輯操作，這些邏輯操作代表著一個復雜的攻擊面，它從沒有消失，只是容易被遺忘。
邏輯缺陷的本質就是設計者或開發者在思考問題過程中做出的特殊假設存在明顯的或隱晦的錯誤，簡單來說，就是程序員可能這么認為：如果發生A，就一定會出現B，因此執行C。但是他們卻忘記了另外一個問題：如果發生X會怎么樣？
下面就是來談談一些常見的邏輯錯誤。
密碼找回功能本意是設計給那些忘記密碼的用戶，以便他們能夠找回自己的密碼。
一般的假設都是這樣的：首先賬號綁定了一個手機或郵箱（以手機為例），然后找回密碼，輸入自己的賬號，然后手機號碼（有些甚至這一步都不需要），然后發送驗證碼（一般是4位或6位純數字，驗證碼有限期很長），然后用戶填寫驗證碼，驗證成功之后，就可以修改賬號的密碼了。
那么問題邏輯缺陷很明顯了，你怎么能只是根據一個驗證碼就確定是用戶本人在修改密碼呢？如果是攻擊者，完全可以暴力破解驗證碼，這樣，任意用戶的密碼都是可以重置的。
烏云類似漏洞
之前的總結文章：密碼找回功能可能存在的問題
在一些網上交易網站上，開發者一般的設計是這樣的：用戶購買商品，然后根據價格，得到一個總價，然后根據總價來扣錢。
那么這樣的一個邏輯處理不當其實會出現很多問題，首先是，如果用戶購買的商品是負數，那么計算的總計就是負數了，這樣的話，系統的處理就會反給錢給用戶，烏云也爆出過這樣的漏洞：
同樣的道理，如果價格沒有控制好（比如越界），為負數的話，也會出現這樣的問題。有時候還不符合邏輯，因為，你的賬上金額顯示為負數。
烏云類似漏洞：
WooYun: UCloud 另一處嚴重支付邏輯錯誤 導致可刷余額
之前的總結文章：在線支付邏輯漏洞總結
這個就以發帖來說明，一般的假設都是這樣的，A發了一篇帖子，這篇帖子的地址是http://xxxx.com/fatie/A, 然后，B用戶發帖，發帖的地址是http://xxxx.com/fatie/B。
那么這樣的設計缺陷有可能出現B修改A發布的帖子的問題。攻擊者B可以發帖，然后截住數據包，將發帖的地址改成A的地址，這樣服務器如果沒有其他的檢查措施，那么A用戶的帖子就會被B用戶修改。同樣的道理，如果B發布一個有害的帖子，那么在發布的時候，只需要將發布的地址修改成A的，那么就可以嫁禍給A了。
同理，A想要查看自己的信息，比如是這么一個形式：http://xxxx.com/look/A/1234。 這是A的自己的敏感信息位置，那么可能存在的缺陷就是A通過將地址修改成http://xxxx.com/look/B/1234去查看B的敏感信息。
烏云類似漏洞：
之前的總結文章：我的越權之道
一些網站對于用戶是否成功登錄不是看用戶名與密碼是否與數據庫里面的匹配，而是看cookies是否為空或session是否為true。這樣的問題的假設就是開發者認為用戶能夠登錄，那么cookies就不會為空或session就不會為false。但是邏輯缺陷很明顯，那么只要能知道用戶ID，然后構造一個cookies或讓session值為true就可以繞過這樣的認證了。
烏云類似漏洞：
有些網站，可能會有這樣的功能：
首先，進行A過程，
其次，進行B過程，
再次，進行C過程，
最后，進行D過程。
開發者的意圖是，用戶必須進行了A才能進行B，進行了B才能進行C，進行了C才能進行D，也認為用戶會按照預定的順序執行每一個步驟，這是因為在瀏覽器中導航是這么處理的。
開發者的假設存在缺陷。用戶控制著他們給應用程序發送的每一個請求，因此能夠按照任何順序進行訪問。于是，可能，用戶就從B直接進入了D過程，就繞過了C。如果C是支付過程，那么用戶就繞過了支付過程而買到了一件商品。如果C是驗證過程，就會繞過驗證直接進入網站程序了。
烏云類似漏洞：
WooYun: 中國教師資格網繞過驗證(可遍歷全國教師身份信息)
WooYun: 萬達某分站邏輯錯誤可繞過支付直接獲得取票密碼
這個缺陷我想主要是針對的12306吧。
網站的假設是每隔5s，票會刷新一次。
但是這個時間確實在本地設置的間隔。于是，在控制臺就可以將這個時間的關聯變量重新設置成1s或者更小，這樣刷新的時間就會大幅度縮短。
烏云類似漏洞：
邏輯缺陷給應用程序帶來的危害是巨大的。我進行了一個簡單的統計，對于BAT3個公司，邏輯缺陷（這里我將邏輯缺陷、權限繞過的比例加在了一起）的比例分別是：百度15%，在所有漏洞中占的比例排第二，阿里巴巴32%，在所有漏洞中排名第一，騰訊27%，與XSS漏洞并列第一。從這3個公司可以看出，邏輯缺陷或邏輯錯誤的危害是相當大的。
那么在實踐中該如何降低邏輯缺陷造成的風險呢？
1、應用程序的設計信息要清楚，詳細的記錄在文檔中，以便他人了解（主要是安全檢查人員）
2、始終記住用戶可以控制請求的每一個方面，他們可以按照任意順序訪問多階段功能，可以提交畸形數據，可以忽略某些參數，可以偽造某些參數，可以修改某些參數。因此在設計的時候一定盡可能要面面俱到。
3、在安全代碼審計的過程中，從各個角度考慮兩個因素：應用程序如何處理用戶的反常操作和輸入的，不同代碼組件與應用程序功能之間的相互依賴操作可能造成不利影響。
4、在安全代碼審計過程中，考慮設計過程中做的每一個假設，并想象假設被違背的每種情況，尤其注意用戶可以完全控制的假設條件。
邏輯缺陷是一個非常常見的問題，因為對于一個設計者，不可能面面俱到，總會有疏漏。那么對于滲透測試員來說就必須從不同的角度考慮問題了。尤其是從異常考慮問題，從而發現應用程序是否是正確處理了異常。
除了基本的測試，在探查邏輯缺陷面臨的最大的挑戰就是，如何深入了解開發者的思維。需要了解他們想要打到什么目的，可能會做什么假設，可能采取哪些捷徑，可能犯下什么錯誤。想想一個項目最后期限到了，開發人員為了完成任務，就會不顧安全。然后就會很容易犯下錯誤。我們想的就是如何利用這些錯誤了。
?