Web登錄認證類漏洞分析和安全驗證機制設計的示例分析

本篇文章為大家展示了Web登錄認證類漏洞分析防御總結(jié)和安全驗證機制設計的示例分析，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

web登錄認證方面，從子功能上可以劃分為登錄框登錄、忘記密碼(密碼重置)、修改密碼、驗證碼、發(fā)送手機驗證碼、發(fā)送郵箱驗證碼、注冊賬號、登錄信息錯誤提示、賬號鎖定等等小功能組成(單點登錄還要講原理，本文暫不涉及)，每個web站點的登錄大約由上面小功能的全部或者一部分組成(這里漏洞缺陷以這些小功能做劃分，更有針對性覆蓋也全面一點，但還是避免不了交叉)。

先從最基礎最常見的開始列舉列：

登錄框

登錄框賬號密碼服務端持久化：當你打開登錄頁面發(fā)現(xiàn)賬號密碼已經(jīng)填好了，點擊登錄直接進后臺哈哈

• 修復方案：保存賬號密碼處理的邏輯針對本地，session及時銷毀

• 信息泄露：登錄框提供個示例用戶名，比如示例郵箱、手機、用戶名規(guī)則導致黑客掌握規(guī)律生成字典

• 修復方案：不顯示示例用戶名

• sql注入：用戶名字段或者密碼字段存在sql注入，比較典型的是萬能密碼登錄(大家都知道)

• 修復方案：使用參數(shù)綁定方式查詢和預編譯語句，如果使用各種框架按照框架安全開發(fā)的要求編程

• XSS：用戶名或密碼字段存在XSS，比較典型的是反射XSS打自己

• 修復方案：使用各種XSS過濾庫編碼庫，詳細請百度，本文不是XSS專題

• 賬號密碼暴力破解：黑客通過工具或者腳本加載賬號密碼字典不斷嘗試登錄

• 修復方案：添加驗證碼(添加驗證碼不對可能導致繞過等，不一定能防止，下文詳說)

• 用戶枚舉：輸入不對的用戶名提示密碼不存在，輸入對的用戶名提示密碼錯誤，從而枚舉用戶名

• 修復方案：使用模糊的錯誤提示，如用戶名或密碼不正確

• 賬號鎖定：用戶爆破的時候錯誤次數(shù)過多鎖定賬號，然后黑客批量嘗試用戶名導致大部分用戶名被鎖

• 賬號詳情泄露：提交合法用戶名，服務器返回關于用戶名相關的賬號、身份、密碼等詳細信息

• 修復方案：使用驗證碼方式防爆破，盡量不要使用登錄次數(shù)太多鎖定的方式，或者設置短時鎖定

• 低頻撞庫爆破：利用腳本以慢頻率持久爆破，針對限制頻率數(shù)字比較大的防御策略

• 修復方案：使用驗證碼機制

圖片驗證碼

• 易識別：驗證碼雜點太少或者沒有雜點導致可以用程序識別出驗證碼的內(nèi)容

• 驗證碼前端生成：驗證碼是用js做的，用js生成點隨機字符填充到前端dom

• 單獨驗證：驗證碼和需要驗證的參數(shù)不在同一個http請求，導致驗證碼認證成功后進行攻擊，比如驗證碼成功后抓到正在的用戶名密碼的請求進行暴力破解

• 置空：當驗證碼的值或者參數(shù)置空的時候，可以直接認證，這是服務端邏輯判斷少了一個驗證碼為空的判斷

• 驗證碼復用：同一個驗證碼可以不限次數(shù)的使用，或者驗證碼用完沒銷毀，導致可以爆破或者任意注冊

• 前端顯示：服務端生成的驗證碼不是圖片，而是字符串直接返回到前端

• 任意值：攔截到http請求，對驗證碼的值設置任意值都能通過驗證碼驗證

• 優(yōu)先級低：同一個http請求到服務端以后驗證碼不是最先驗證的，比如先驗證用戶名，導致用戶枚舉

• 打碼平臺：使用打碼平臺調(diào)用驗證碼接口獲取驗證碼進行識別，返回驗證碼

• 修復方案：驗證碼必須要在服務端生成添加雜點干擾項并足夠扭曲以圖片格式返回前端，前端帶驗證碼和需要驗證參數(shù)在一個請求里發(fā)送到服務端，服務端第一優(yōu)先級先驗證驗證碼的存在性和正確性，一個驗證碼使用一次后銷毀

手機和郵箱驗證碼

• 前端顯示：服務器生成的驗證碼返回到頁面前端，導致前端可以看到產(chǎn)生驗證信息泄露

• 復雜度低：由4位數(shù)字組成的驗證碼，如果服務端沒次數(shù)限制可以枚舉出來進行登錄或者注冊

• zha_蛋：通過腳本不斷向驗證手機號或者郵箱發(fā)送短信或者郵件，導致接收方接受大量垃圾信息

• 賬號鎖定：單個手機或郵箱一定時間超過某次數(shù)鎖定一定時間，自動化批量鎖定賬號

• 不匹配：比如同請求用戶名和手機不匹配但依舊發(fā)送驗證碼，導致可以向任意號碼發(fā)短信

• 資費消耗：有單個手機號次數(shù)限制，使用大量不同手機號短時間內(nèi)發(fā)送數(shù)萬級短信

• 修復方案：驗證碼要有一定的復雜度，至少6位，不能返回前端，基于基于客戶端session進行次數(shù)限制，制定合適的鎖定策略，對比賬號和綁定的手機郵箱是否匹配

忘記密碼

• 賬號枚舉：你輸入用戶名提交以后系統(tǒng)提示用戶不存在等

• 認證方式篡改：輸入合法用戶名以后輸入其他郵箱或者手機可以接受到驗證碼

密碼重置

• 驗證碼繞過：圖片驗證碼或手機驗證碼和被重置的賬號不在同一請求或者利用文中技術繞過

• 用戶枚舉：通過重置接口判斷用戶是否存在，獲取用戶名

• 任意賬號重置：系統(tǒng)通過用戶名和密碼倆參數(shù)進行密碼重置，導致任意賬號密碼都能重置

• 認證方式篡改：輸入合法用戶名，使用黑客的郵箱或者手機接收到系統(tǒng)重置的密碼

• 修復方案：判斷賬號和綁定驗證方式的合法關系，重要請求中要帶有驗證碼機制，對不存在或者不正確的賬號采用模糊的報錯提示信息

任意注冊

• 用戶枚舉：注冊時系統(tǒng)提示用戶名已注冊，批量枚舉用戶

• 驗證碼繞過：使用正確的圖像驗證碼或者手機郵箱驗證碼后，再提交注冊信息，其他繞過方式見上文

• sql注入：注冊字段沒有預編譯參數(shù)綁定，導致注入

• 手機驗證碼爆破：手機或者郵箱的驗證碼太短，不強壯被暴力破解

• 修復方案：把驗證碼和注冊信息在同一請求提交，服務端優(yōu)先驗證驗證碼是否正確，驗證碼機制見上文

組合繞過

通過上文各種安全繞過技術，我們可以嘗試一種或多種手段繞過驗證碼、手機驗證等等，總會有各種各樣的小漏洞被組合繞過進而進行攻擊，具體的看認證機制使用了哪些防御措施，比如是否使用圖片驗證碼、手機驗證碼、用戶枚舉、等等吧

安全的認證機制

上文中，關于認證的攻擊繞過那么多，那么樣的認證機制是安全的?上面重放攻擊那么多，什么是對抗重放攻擊最有效的手段?

對于可以使用腳本或者程序自動化攻擊的，最有效的防御手段就是驗證碼!!

防御手段有哪些關鍵點呢?

如何盡可能的避免各種邏輯繞過的漏洞?最好減少人造石步驟，甚至把需要認證的參數(shù)全放一個http請求中!

• 對于參數(shù)過濾，可以使用正則匹配就使用正則，比如郵箱、手機、***使用正則驗證，完全可以避免sql注入XSS這些

• 對于不能使用正則匹配的，對參數(shù)使用owasp等組織開源的過濾庫防止XSS

• 對于同一個http請求的參數(shù)，驗證碼擁有最高優(yōu)先級驗證，驗證碼驗證時要驗證其存在性、參數(shù)的存在性、一次性

• 盡量不要使用接口，因為接口一般不能使用驗證碼

• 往前端返回信息，使用最小信息原則，只返回必要的信息

一個安全的認證機制的設計

• 登錄功能：把用戶名密碼和其他需要的字段(如驗證碼，驗證碼只有一次，并足夠雜點和復雜度)放前端讓客戶一起填寫，然后放到同一個http請求提交給后端，后端判斷是否有驗證碼參數(shù)，然后判斷驗證碼是否正確，再然后正則判斷部分字段，不能正則的對參數(shù)進行過濾轉(zhuǎn)碼，然后使用參數(shù)綁定和預編譯查詢數(shù)據(jù)庫，出錯或者不存在的提示前端用戶名或者密碼錯誤，這樣就防止了自動化攻擊和SQL注入信息泄露等等

• 密碼重置功能：把驗證碼、用戶名、認證因子(郵箱、手機等)放到同一個http請求中，優(yōu)先驗證驗證碼的存在性、正確性、一次性，其次對參數(shù)進行正則格式驗證、之后對不能驗證參數(shù)進行過濾編碼、驗證用戶名和認證因子的匹配性、最后再觸發(fā)相關功能

上面兩種情況，即使攻擊者想撞庫、鎖定賬號、批量重置等操作，也會因為驗證碼而只能影響個位數(shù)的賬號，對系統(tǒng)整體影響不大。

其他功能同理，要結(jié)合實際的場景進行設計，即可把風險控制到最小!

上述內(nèi)容就是Web登錄認證類漏洞分析防御總結(jié)和安全驗證機制設計的示例分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業(yè)資訊頻道。