應用程式邏輯錯誤總結

0x00 引言

---

所有應用程式都是透過邏輯實現各種豐富多彩的功能的，要實現這些功能，必須掌握大量的技巧並進行周密的安排。但是，有很多情況這些功能邏輯存在缺陷，比如程式設計師的安全意識，比如考慮問題不周全等。即使是最簡單的web應用程式，每個階段都會執行大量的邏輯操作，這些邏輯操作代表著一個複雜的攻擊面，它從沒有消失，只是容易被遺忘。

邏輯缺陷的本質就是設計者或開發者在思考問題過程中做出的特殊假設存在明顯的或隱晦的錯誤，簡單來說，就是程式設計師可能這麼認為：如果發生A，就一定會出現B，因此執行C。但是他們卻忘記了另外一個問題：如果發生X會怎麼樣？

下面就是來談談一些常見的邏輯錯誤。

0x01 欺騙密碼找回功能

---

密碼找回功能本意是設計給那些忘記密碼的使用者，以便他們能夠找回自己的密碼。

一般的假設都是這樣的：首先賬號繫結了一個手機或郵箱（以手機為例），然後找回密碼，輸入自己的賬號，然後手機號碼（有些甚至這一步都不需要），然後傳送驗證碼（一般是4位或6位純數字，驗證碼有限期很長），然後使用者填寫驗證碼，驗證成功之後，就可以修改賬號的密碼了。

那麼問題邏輯缺陷很明顯了，你怎麼能只是根據一個驗證碼就確定是使用者本人在修改密碼呢？如果是攻擊者，完全可以暴力破解驗證碼，這樣，任意使用者的密碼都是可以重置的。

烏雲類似漏洞

WooYun: 華為網盤部分使用者密碼修改

之前的總結文章：密碼找回功能可能存在的問題

0x02 規避交易限制

---

在一些網上交易網站上，開發者一般的設計是這樣的：使用者購買商品，然後根據價格，得到一個總價，然後根據總價來扣錢。

那麼這樣的一個邏輯處理不當其實會出現很多問題，首先是，如果使用者購買的商品是負數，那麼計算的總計就是負數了，這樣的話，系統的處理就會反給錢給使用者，烏雲也爆出過這樣的漏洞：

WooYun: destoon無限制增加帳號資金

同樣的道理，如果價格沒有控制好（比如越界），為負數的話，也會出現這樣的問題。有時候還不符合邏輯，因為，你的賬上金額顯示為負數。

烏雲類似漏洞：

WooYun: UCloud 另一處嚴重支付邏輯錯誤 導致可刷餘額

之前的總結文章：線上支付邏輯漏洞總結

0x03 越權缺陷

---

這個就以發帖來說明，一般的假設都是這樣的，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的敏感資訊。

烏雲類似漏洞：

WooYun: 益雲公益廣告越權修改漏洞

之前的總結文章：我的越權之道

0x04 cookies和session的問題

---

一些網站對於使用者是否成功登入不是看使用者名稱與密碼是否與資料庫裡面的匹配，而是看cookies是否為空或session是否為true。這樣的問題的假設就是開發者認為使用者能夠登入，那麼cookies就不會為空或session就不會為false。但是邏輯缺陷很明顯，那麼只要能知道使用者ID，然後構造一個cookies或讓session值為true就可以繞過這樣的認證了。

烏雲類似漏洞：

WooYun: 益雲廣告平臺任意帳號登入

0x05 順序執行缺陷（強制瀏覽）

---

有些網站，可能會有這樣的功能：

首先，進行A過程，
其次，進行B過程，
再次，進行C過程，
最後，進行D過程。 

開發者的意圖是，使用者必須進行了A才能進行B，進行了B才能進行C，進行了C才能進行D，也認為使用者會按照預定的順序執行每一個步驟，這是因為在瀏覽器中導航是這麼處理的。

開發者的假設存在缺陷。使用者控制著他們給應用程式傳送的每一個請求，因此能夠按照任何順序進行訪問。於是，可能，使用者就從B直接進入了D過程，就繞過了C。如果C是支付過程，那麼使用者就繞過了支付過程而買到了一件商品。如果C是驗證過程，就會繞過驗證直接進入網站程式了。

烏雲類似漏洞：

WooYun: 中國教師資格網繞過驗證(可遍歷全國教師身份資訊)

WooYun: 萬達某分站邏輯錯誤可繞過支付直接獲得取票密碼

0x06 時間重新整理缺陷

---

這個缺陷我想主要是針對的12306吧。

網站的假設是每隔5s，票會重新整理一次。

但是這個時間確實在本地設定的間隔。於是，在控制檯就可以將這個時間的關聯變數重新設定成1s或者更小，這樣重新整理的時間就會大幅度縮短。

烏雲類似漏洞：

WooYun: 12306自動刷票時間可更改漏洞

0x07 避免邏輯缺陷一些建議

---

邏輯缺陷給應用程式帶來的危害是巨大的。我進行了一個簡單的統計，對於BAT3個公司，邏輯缺陷（這裡我將邏輯缺陷、許可權繞過的比例加在了一起）的比例分別是：百度15%，在所有漏洞中佔的比例排第二，阿里巴巴32%，在所有漏洞中排名第一，騰訊27%，與XSS漏洞並列第一。從這3個公司可以看出，邏輯缺陷或邏輯錯誤的危害是相當大的。

那麼在實踐中該如何降低邏輯缺陷造成的風險呢？

1、應用程式的設計資訊要清楚，詳細的記錄在文件中，以便他人瞭解（主要是安全檢查人員） 
2、始終記住使用者可以控制請求的每一個方面，他們可以按照任意順序訪問多階段功能，可以提交畸形資料，可以忽略某些引數，可以偽造某些引數，可以修改某些引數。因此在設計的時候一定儘可能要面面俱到。 
3、在安全程式碼審計的過程中，從各個角度考慮兩個因素：應用程式如何處理使用者的反常操作和輸入的，不同程式碼元件與應用程式功能之間的相互依賴操作可能造成不利影響。 
4、在安全程式碼審計過程中，考慮設計過程中做的每一個假設，並想象假設被違背的每種情況，尤其注意使用者可以完全控制的假設條件。

0x08 結束語

---

邏輯缺陷是一個非常常見的問題，因為對於一個設計者，不可能面面俱到，總會有疏漏。那麼對於滲透測試員來說就必須從不同的角度考慮問題了。尤其是從異常考慮問題，從而發現應用程式是否是正確處理了異常。

除了基本的測試，在探查邏輯缺陷面臨的最大的挑戰就是，如何深入瞭解開發者的思維。需要了解他們想要打到什麼目的，可能會做什麼假設，可能採取哪些捷徑，可能犯下什麼錯誤。想想一個專案最後期限到了，開發人員為了完成任務，就會不顧安全。然後就會很容易犯下錯誤。我們想的就是如何利用這些錯誤了。