這個部分我會講的比較深入，所以就決定分成兩天來講了。
這篇會注重於基礎以及例子，偏向純資訊安全的角度
下一篇將會注重於邏輯漏洞在CTF的實踐，大家可以根據自己的情況選擇合適的篇章閱讀哦！

邏輯漏洞

邏輯漏洞logical vulnerabilities非常容易理解：指的就是程序基於邏輯或設計上涉及錯誤或者有不嚴謹的部分，以致程序出現不正常的行為或者安全措施被繞過。

種類

邏輯漏洞有非常多的種類，我把最常見的出現邏輯漏洞的地方分別分成了：

• 帳號系統安全
• 業務數據安全
• 權限安全

常見的邏輯漏洞

1. 帳號系統安全

1-1 註冊

• 重複的使用者名稱未被正確處理
• 用戶名大小寫、前後空格未被正確處理
• 用戶名枚舉 User Enumeration：透過註冊過程中的「該帳號已存在」或「該電子郵件已被註冊」一類訊息、或甚至是回應時間差異，判斷甚麼電子郵件已經被註冊

1-2(I) 密碼

• 密碼保存沒有經過哈希(Hash - 又稱雜湊)演算法變換 -> 入侵資料庫可直接獲得密碼明文
• 沒有限制用戶密碼長度 -> 密碼容易破解/過長密碼導致問題

1-2(II) 找回密碼/修改密碼

• 舊密碼未被確認
• 驗證邏輯不在伺服器端，可以透過更改Request繞過驗證

1-3 [重點] 驗證碼安全

這個問題較為常見，於是會詳細講一講：
注：這裡指的驗證碼是確認用戶不是機器人的那種驗證碼
驗證碼安全一般指驗證碼沒能達到驗證作用。這可以是因為驗證邏輯在用戶端，或者驗證碼可以輕鬆被破解、識別。這會導致用戶能夠暴力破解Brute Force的問題。
識別方式：
輸入任意帳號資訊、正確以及錯誤的驗證碼，擷取發送到伺服器端的請求Request，然後利用Burp Suite一類工具使用其他資訊重複請求，檢查錯誤驗證碼會否被伺服器偵測；
亦可嘗試登入多次，查看驗證碼是否有特定規則可以預測；
也可以嘗試一般OCR工具是否可以識別驗證碼；
若驗證碼的組合不多，如驗證碼必定是四位數字，也可以嘗試暴力破解。

2. 業務數據安全

2-1 [重點] 訂單金額修改

這是一種支付漏洞。(雖然涉及支付，也有可能在CTF中實現；相關資訊將在下一篇提及)
一般指的是伺服器沒有對訂單的金額進行驗證，使用者可以修改訂單的金額，以自訂價格購買商品。
識別方式：
生成訂單期間/後擷取網絡請求，直接修改發送/收到的訂單金額。某些情況更可嘗試負數金額。

2-2 [重點] 數據爭用

有些伺服器可能存在未被正確處理的並行處理系統，導致使用者可以透過極短的時間內發出大量請求，使得伺服器在第一個請求成功更新資料庫資訊之前，使用了未更新的資訊執行其他請求。
這問題在購物平台之類的平台上尤其嚴重：你可以在極短時間內購買同一項商品數次，伺服器在處理請求期間因為資料庫未在執行其他請求期間更新，統一使用購買商品前的餘額扣帳，導致實際只支付了一次金額。

3. 權限安全

• 未授權訪問
  • 特定含有敏感資訊的管理頁面不需要驗證身分，可以透過對主域名進行爆破獲得管理頁面url
  • 靜態文件訪問沒有設置認證
• 水平越權：使用者可以存取相同權限的其他使用者信息(透過例如更改url參數ID等技巧)
• 垂直越權：使用者可以透過例如更改url參數ID等的技巧進行比起自己權限更高的操作

以上，就是最常見的邏輯漏洞種類了。
如果想要更詳細了解的(包括以上漏洞如何修復)，不妨參考一下這篇文章：
https://cloud.tencent.com/developer/article/2091084 (簡中)

下一篇將會講解這些漏洞可以如何利用在CTF挑戰~