驗證碼安全那些事。最近在研究驗證碼安全，本文主要分析四種流行的驗證碼(圖形，短信，語音和滑動)進行分析，寫這篇文章的出發點并非是繞過或破解驗證碼，而是根據自身業務情況來選擇對應的驗證碼類型，在用戶體驗和安全性中找到屬于自己的平衡點。

　　有問題可與我聯系Wechat：atiger77

　　目錄

　　0×01. 圖形驗證碼

　　0×02. 短信驗證碼

　　0×03. 語音驗證碼

　　0×04. 滑動驗證碼

　　0×05. 總結

　　備注：無論使用哪種驗證碼，只要開發不當都可能存在安全漏洞，為了減少文章重復內容，只在短信驗證碼中講解漏洞以及對應加固方案，在語音驗證碼中講解風控預防措施。

　　0×01 圖形驗證碼

　　圖形驗證碼是出現最早也是使用最為廣泛的驗證碼沒有之一，從最早的簡單驗證碼到現在各種五花八門的驗證碼，為了防止被識別有加噪點的，有加干擾線的，有加各種背景的，有加邏輯題的…

　　之所以會有越來越惡心的驗證碼主要是防止驗證碼被機器識別，所設計的驗證碼難度也在不斷上升，相比較來看下面兩張圖就知道為什么會這么設計了。

　　一般識別流程:

　　一般驗證碼加固方法：

　　隨著驗證碼難度的提高識別的成本也隨即提高，為了進行識別測試，我分別收集了四家不同類型互聯網公司的驗證碼，情況如下：

　　某招聘網站驗證碼 – 字母周圍有噪點，字體扭曲

　　某電商網站驗證碼 – 不同樣式，字母陰影，字母粘連，背景色干擾

　　某社交網站驗證碼 – 主體干擾線，背景色干擾，背景字母干擾，字體扭曲，字母粘連

　　某生活類網站驗證碼 – 背景干擾線，背景色干擾，背景字母干擾，字體扭曲，字母粘連，字體鏤空

　　首先針對某招聘網站的驗證碼進行識別，這里基于tesseract寫的一個OCR程序,測試樣本10張，最后準確率在50%，反溯以下發現對識別相近字時會比較吃力比如”z”和”2″，”0″和”O”等等，因為驗證碼做了反識別部分驗證碼人眼也比較難識別，如果繼續優化識別率達到70%左右應該問題不大。

　　接著對某電商網站的驗證碼進行識別，最后準備率在40%，由于該網站驗證碼難度各不相同對于這種類型的驗證碼比較難做統一處理，即使使用機器學習的方法一個模型也很難去識別所有的驗證碼。

　　后面兩個網站的驗證碼使用圖像識別去做難度就很高了，為了不被識別分別做了大量的反識別工作，那么對于這類驗證碼一般使用的是人工打碼平臺，之前有文章已經介紹過了這里就不重復描述了。

　　這是某打碼平臺的價格，網上可以找到很多類似的網站。

　　那么對于企業來說，怎么防止驗證碼被人工打碼呢，從安全角度來說是比較難做到防止的，為了不失去用戶體驗每張驗證碼的失效時間并不會很短，對于一個熟練的人工打碼人員來說完全不在話下，那么我們從驗證碼本身出發去提高攻擊的一個成本，舉一個例子，可以使用DataURI scheme的方法把驗證碼圖片直接寫到HTML文件中去增加識別的時間和成本，當然還會有很多方法可以去增加攻擊成本。

　　如果想從根本去除打碼平臺的困擾，這里可以參考支付寶和微信這兩個產品的驗證碼機制，在某些地方所彈出的圖形驗證碼是和使用者有關，比如選擇聯系人頭像，選擇購買過的物品，對于人工打碼的人來說是完全不知道答案的，但是用了這種類型的驗證碼也會出現問題，比如“好友”足夠了解你的情況下(個人信息泄露太多)可能會成功的進入。

　　現在有很多文章會用到神經網絡CNN的方法用來識別驗證碼，相比傳統的識別用機器學習有了樣本的學習，識別率會更加的準確，對一些人眼可能判斷錯誤的字母機器或許能判斷準確，不過學習成本也是很高的。

　　0×02 短信驗證碼

　　短信驗證碼常見于注冊，忘記密碼，確認下單等階段，特別是一些涉及到用戶個人敏感行為時候，為了確認操作是用戶本人執行的通常會使用短信驗證碼進行二次認證。同時，短信驗證碼也是最為常見的驗證碼類型之一，這里總結一些驗證碼邏輯漏洞。

　　a. 接口沒設頻次上限導致短信轟炸

　　起因：短信轟炸問題往往出現在一些小站或者子站，這幾年很少看到通過GET請求發送短信驗證碼了，基本都是使用POST請求，使用抓包軟件可以重放請求對于后端沒有做限制的網站就可以達到短信轟炸的效果。

　　危害：對用戶來說個人生活受到騷擾，對企業來說造成一定的負面影響，很多小公司因為短信接口被大量調用出現運營問題，對于公司沒有安全工程師的情況下，一般都是業務方發現了數據異常向上匯報，最后和開發一起反溯才會找到這個問題，那么在這段時間中對企業所損失的錢也是無法挽回的。

　　預防：這里主要是針對兩種攻擊場景來進行防御，第一種是對單用戶的短信轟炸，即重放發送請求且phonenum為一個值。第二種是對多用戶發送短信騷擾的場景，即將phonenum參數設置為字典，重放短信接口。

　　設置發送間隔，即單一用戶發送請求后，與下次發送請求時間需要間隔60秒。

　　設置單用戶發送上限，即設置每個用戶單位時間內發送短信數的上限，如果超過閾值就不允許今天再次調用短信接口(閾值根據業務情況設置)。

　　設置單IP發送上限，這種情況是預防第二種攻擊場景的，由于IP的特殊性可能存在所處IP是大出口，一旦誤殺后果會很驗證，所以這個限制根據自身情況酌情考慮，對于有風控的團隊來說，當發現發送IP存在異?？梢詫υ揑P增加二次認證來防止機器操作，也可以降低誤殺情況。

　　備注：b和c兩個漏洞場景一般截圖說明下開發就知道問題所在了，這里修復建議的內容寫的就比較少。

　　b. 驗證碼內容包含在返回包中

　　起因：因為開發不嚴謹導致通過抓包可以看到驗證碼在回顯中顯示。

　　危害：由于驗證碼直接返回，通過該漏洞可以注冊任意用戶，重置已注冊用戶密碼，修改綁定信息等高危操作，對用戶造成一定影響。

　　修復建議：不要將短信驗證碼在回顯中顯示，驗證碼只存于服務端中并不能通過任何api直接獲取。

　　c. 修改返回包內容繞過驗證

　　起因：前端校驗導致下列問題。

　　危害：可跳過正常校驗邏輯。

　　修復建議：服務端嚴格做檢驗，和開發談談心。

　　假設網站驗證碼接口沒有以上說的任何漏洞，那么短信認證是否安全呢?

　　在用戶手機沒有被種木馬，用戶手機沒被強制降頻到GSM等情況下，當攻擊者無法獲取短信驗證碼則某些關鍵操作是無法繼續的，在一定程度上起到了攔截的作用。特別針對盜號的場景，由于設備或常用地發生了變化，在用戶登錄時候彈出驗證碼進行校驗防止被盜號的情況。短信驗證碼只對部分場景可以起到防護作用，單一的認證對于企業來說無法阻止以下的場景。

　　這張圖在我上一篇文章中出現過，這是在某打碼平臺注冊了一個帳號的截圖，從圖上就可以看出雖然用了短信驗證碼，但是可以通過打碼平臺來自動獲取并完成注冊流程。

　　針對打碼平臺的垃圾注冊場景也可以通過一些手段去增加批量自動化的注冊成本，防御手法有相同之處，在語音驗證碼中會簡單講解。

　　0×03 語音驗證碼

　　相比短信驗證碼，語音驗證碼存在以下的優勢：

　　a.語音驗證對防刷單效果更顯著;

　　b.語音驗證碼到達率更高;

　　c.用戶體驗更加友好;

　　為什么說語音驗證碼對防刷單更有效，這里貼一張某打碼平臺的收費情況，可以看到語音驗證的價格是短信的十倍。很多公司是不會對17開頭的虛擬號段進行發送的，為此卡商提供的卡號基本是實名認證的且沒有停機的正常號段，所以收語音驗證的成本就會比短信高很多。

　　這家打碼平臺對語音識別有兩種方式，一個是系統識別，另一個是自己聽取，對于系統識別平臺解釋是由聽碼團隊負責聽取驗證碼后傳輸文字回來，自己聽取則是自己下載語音驗證碼錄音自己聽候識別。

　　跟公司研究移動端安全的小伙伴討論了下，根據目前的技術要做到全自動也并非不可能，這里簡單畫了一個流程，從觸發語音認證開始到最后的填入完成驗證一條龍。

　　首先要獲取語音認證，等語音驗證碼說完以后自動保存錄音，進行語音分析，國內有幾家廠商有語音識別的服務并都提供SDK，所涉及的服務可以用來進行識別，將語音轉換成文字并提取驗證碼部分，完成最后驗證。

　　對于企業來說我們如何防止這種垃圾注冊的場景呢，說幾種通用的思路供參考，這里主要可以分事前和事后基于規則和行為做判斷。

　　對于事前，可以借助反欺詐接口檢測請求的號碼是否存在風險，WEB端判斷用戶UserAgent是否存在異常，APP端判斷用戶DeviceID是否存在異常，由于事前可以拿到的信息并不多，可以圍繞可以拿到的參數做規則，對觸發規則的用戶進行阻斷操作，可以在發送短信或者語音前讓其先填寫一次圖形驗證碼，多一步校驗。當然，也有公司會將部分手機號進行拉黑操作，在源頭上禁止某些手機號進行注冊。

　　對于事后，服務端校驗以后就可以拿到狀態等信息，圍繞這些信息又可以制定一些規則，這里可以舉一個通用的規則，比如單位時間內單IP登錄失敗超過閾值的對這個IP進行某某處理，這也是最基本的頻次規則。對于不同的業務有著自己不同的策略，比如金融公司的APP會索取用戶通訊錄的權限，根據用戶的好友做用戶畫像，某些公司也會做二度關系畫像來判斷用戶是否存在風險。

　　這里不會說太多的規則和策略，由于公司的業務都不盡相同，當日志接入以后針對目前場景存在的問題去設計不同的規則即可。

　　0×04 滑動驗證碼

　　現在有不少的互聯網公司開始使用滑動驗證碼進行校驗，看似一個簡單的滑動操作，背后都有風控引擎和相應的規則作為保障，首先講一下滑動驗證碼的整個流程。

　　我們說一下正常的邏輯，首先用戶滑動驗證碼到指定位置，完成后會給服務端回傳各種加密信息，為了做風控規則來判斷是否異常，個人猜測其規則會包含用戶IP，操作行為路徑，UA,COOKIE，設備指紋等等，如果沒有命中規則，就會放行校驗通過，如果命中規則就會彈出二次校驗，只有通過校驗后才可以放行。

　　那么如何破解滑動驗證碼呢，第一種是模擬正常用戶操作，并讓風控不要命中風控規則。第二種是嘗試破解第二階段的驗證，對于圖片可以使用OCR技術進行識別(針對類ReCAPTCHA驗證碼)。第二種的難度比較高，網上的文章也是針對第一種來進行破解，這里簡單講一下破解方法。

　　我對某商業滑動驗證碼進行了測試，整體流程梳理如下：

　　全部過程可以用自動化來實現，整體成功率要分為兩個部分來看，第一是驗證碼自身風控能發現多少問題，我所測試的接口破解成功率在76%左右。第二是企業自身的風控規則能發現和阻斷多少異常情況。兩者結合最后的成功率就會有所下降，雖然有接口破解但是價格昂貴，已經提高了攻擊成本，如果賬戶不涉及到金錢也不會考慮這么高的攻擊成本，其實說到底還是成本和收益的一個衡量。

　　這里聊一下商業化滑動驗證碼廠商的優勢和弊端。首先說優勢，滑動驗證碼肯定會成為一種流行趨勢，對于企業來說自研的成本比較大，無非也就是幾個工程師參考已有的進行模仿，先不說效果開發流程上就會耽誤人力，這點錢寧愿使用商業化的，現在的產品都已經相對成熟也有專門的團隊進行升級維護，安全和體驗性上來說都還不錯。弊端到也談不上，這里主要說幾點使用前要考慮的地方，一個是響應延遲，當大量并發過來的時候是不是撐得住，最高響應時間是否有上限，如果超過是否會降級，如何降級等等，萬一碰到不可預計的問題，比如碰到光纜被挖斷，服務是否能即使切換，災備是否完善等等，在購買前這些問題最好都要進行測試并有應急方案。

　　0×05 總結

　　前面也總結了很多驗證碼，我認為一個好的驗證碼首先不能有邏輯上的漏洞能繞過，否則再復雜的驗證碼都是形同虛設。其次，不能為了增加破解難度而拋棄用戶體驗，不要把驗證碼做的極其復雜人眼都識別不了，這種也會失去驗證碼的意義(用戶都沒了還給誰驗證…)

　　目前來說大部分的企業還是偏向使用圖形驗證碼，在測試過程中只有極少數的公司會動態升級自己的圖片驗證碼，隨著輸錯次數的上升驗證碼難度也隨機上升。統一驗證碼的設計初衷是好的，即使攻擊者使用了OCR技術進行破解，一旦失敗數觸發到閾值即自動上升圖形驗證碼難度，增加破解成本。

　　為了防止驗證碼被爬蟲獲取后專門進行分析，針對性的破解攻擊，需要準備多套圖形驗證碼定期進行替換。

　　統一驗證碼體系如果只用單純的規則去匹配所彈出的驗證碼，那么這種情況會出現不少的誤殺，會讓某些正常用戶操作頻次超過設定閾值，用戶在嘗試輸入密碼的過程中驗證碼越來越難，最后導致用戶投訴。所以我認為一個完善的統一驗證碼體系應該由風控來判斷是否觸發規則，對觸發規則的請求進行相應的驗證升級，而不是設定一個死的閾值，對關鍵操作可以用多種驗證碼組合的形式來進行校驗，常見的組合有，滑動+圖形，圖形+語音等。

　　就我個人而言，比較喜歡點觸式和滑動式的驗證碼，通過采集用戶當前各種的參數行為(行為軌距，操作時間，當前環境等等)來判斷是否為機器行為。在用戶體驗上，手機端不是很建議使用選字類型的驗證碼，對于非大屏的手機不是很友好。在安全性上，這類驗證碼要比其他驗證碼破解成本高。我相信驗證碼的趨勢也會逐漸向這種類型的靠攏。

　　下面的圖片引用了google的ReCAPTCHA，分別截取圖片和語音驗證，ReCAPTCHA在安全性和用戶體驗做的都很好，即使這樣還是被安全研究者破解過，所以不要完全依賴一種驗證碼，對敏感操作可以使用多種驗證碼。下面是官網的DEMO：

　　圖片類：

　　聲音類：

　　無論哪種驗證碼都有自己的適用場景，也沒有一種絕對安全的驗證碼，根據自身業務情況來選擇對應的驗證碼類型，在用戶體驗和安全性中找到屬于自己的平衡點。最后，有做業務安全的同學可以一起學習交流?！　?/p> 人妻精品一区二区三区_好紧好湿好硬国产在线视频_亚洲精品无码mv在线观看_国内激情精品久久久

<menuitem id="zjj55"></menuitem>

<menuitem id="zjj55"></menuitem>

<big id="zjj55"></big>

責任編輯：韓希宇