【業務安全】業務安全之另類隐患

有時候，乙方不能感受甲方的痛；

有的漏洞，乙方不會碰到甲方的場景；

不是因為技術不夠強，隻是由于缺少對業務足夠深入的了解。

在漏洞回歸的時候，也會發現新的隐患；

一條短短的驗證碼，可能釀成一場事故；

業務安全之另類隐患，希望和大家分享鮮有人說的點點滴滴。

1、系統登入處暴力破解

某業務系統在修複安全問題，并進行部分功能調整後進行安全提測，内容如下：

接收到提測郵件後，安全測試人員首先對已知漏洞在測試環境進行驗證。使用burp對登入接口進行枚舉驗證：

當發現可枚舉問題還未修複完善時，立即停止了爆破并打回相關漏洞。

一切都是正常操作，不過不久之後，有不少使用者回報收到上述業務系統發出的短信驗證碼。不幸的是正好命中一位公司高管，據其描述最近總收到測試環境的驗證碼且有多條，一聲令下要求追溯發信源頭，并将收到短信驗證碼一事定級為安全事故。由此，資訊安全組便成了肇事者，身背故障分。

登入接口設計存在缺陷：

輸入使用者名和密碼，若驗證成功則對該使用者發送短信驗證碼

測試環境使用生産資料：

為了友善測試，開發将其他資料庫的真實手機号等資訊同步至相關測試資料庫，導緻大量真實使用者收到測試環境短信驗證碼

提測缺失重大變更資訊：

開發未同步使用者的密碼，系統新增的同步使用者統一被設定初始弱密碼，且登入接口有重大變更，未在提測資訊彙總進行描述

從安全的角度出發，在此次事件有點冤。但事已至此，吃一塹需要長一智，在痛苦的經曆中學習提高，關于對業務可能造成高風險危害的操作盡量少做或不做：

漏洞掃描、漏洞利用等高危操作，盡量做到事先告知業務方

安全測試前先評估影響範圍，盡量確定對業務和使用者無影響

安全測試時盡可能主動了解業務形态及功能變更等多種情況

某系統在密碼找回處，可以通過工号或手機号進行找回。

當輸入存在的工号或已注冊手機号時，response傳回手機号：

當輸入存在的工号或已注冊手機号時，系統自動發送四位數字短信驗證碼：

看到這裡，很多人都會想到任意使用者密碼重置漏洞的場景：

通過第一步可以枚舉出已經注冊的使用者，

從第二步獲知純數字的四位驗證碼很容易爆破，

此時還需要看看該接口是否可以枚舉：

雖然使用者名和密碼加密，但該接口還是可以進行枚舉。使用一些小技巧不難加密使用者名和密碼，是以該系統此處功能存在嚴重漏洞，且已經有利用成功的案例：

面對有圖有真相的任意使用者密碼重置漏洞，開發立即響應進入漏洞修複階段，對使用者名密碼驗證頻率和次數進行了限制，降低了漏洞帶來的風險。

在回歸驗證時，原漏洞在和産品的溝通下，算是基本修複。

然而事情往往沒這麼簡單，靜下心來分析發現了更加隐蔽的安全隐患：

可發短信至任意使用者(包括上司)，同上一個場景一樣，又是隻有甲方才能深刻體會到的風險。

業務方面的安全隐患，可能不僅僅是由于業務邏輯造成，其他不規範的操作也起到一定的助攻成分。

業務相關的漏洞修複，推動改起來甚至比web漏洞更加難，因為産品要考慮友好度和便捷性。不過也可以找到其他次之的修複方案，在安全和業務之間找到平衡點，讓安全真正的為業務保駕護航。