登錄博客園時，看到的界面是左邊這樣的，驗證碼錯了一次之后就變得更加扭曲了。
以前博客園不會在第一次訪問頁面的時候彈出驗證碼來，這樣的體驗很不好。
驗證碼作為防機器人的標准套件，已經在無數場合被證實有效。
當然簡單易識別的驗證碼，OCR就可以搞定，然后機器人該來的來。
復雜一點的驗證碼，歪歪曲曲的連正常用戶都看不清，效果並不好。
后來出現的滑動驗證碼、點擊圖片的驗證碼，用戶體驗和安全性都得到了巨大的提升。
隨着圖像識別精准率的大幅提高，12306曾經遇到過圖庫被遍歷，再調用百度接口識別圖片，饒過驗證碼的問題。
即便安全領域做到頂尖水平的Google CAPTCHA就在不久前也被人破解過，有哪家敢說做得比Google還好呢？
我只是不喜歡圖形驗證碼，太麻煩了。然而對絕大多數團隊來說，如果不用驗證碼是防不住機器人的。
國外研究Bot行為的公司Distil做得相當不錯，還有一家公司叫ShapseSecurity可謂防機器人新技術的業界先驅。他們並沒有使用一些很復雜的操作來做這件事情，而是深入到防機器人的場景和原理，從更底層的技術上Anti Bad Bot。
國內更普遍看到的是阿里雲、同盾這樣的從風控着手的解決方案，比如老外這家叫shieldsquare的公司我覺得思路也差不多，都需要基於海量大數據、雲平台、信譽庫或者嵌入到應用代碼中。並不是說這些做法不好，但如果考慮這樣一種場合：Bot使用的IP是多源分布的（10W級別）、請求的頻率接近正常人甚至更低、沒有任何攻擊特征，除非是帳號關聯了IP等信息限制異地操作，純風控層面的解決方案並不理想。從業務層面來看，如果不在黑名單中且行為特征（頻率、數據包）無明顯異常，那么通過機器人進行批量注冊/登錄（雲打碼、短信貓池）、灌水刷評論、領取獎勵這些行為，現有風控機制（設備指紋等）最起碼是無法實時阻斷的。最終你也許可以限制或凍結交易，但大量的虛假信息（比如信用卡申請場景）仍需人工處理，而這樣的操作成本是高昂的（信用卡申請需要調用公安系統接口驗證個人信息是否屬實）。
現在介紹另一種思路和方案，它由國內安全創新公司瑞數信息率先實現（目前唯一）。技術原理上來說，它仍會用到諸如阿里雲使用的設備指紋、用戶行為信息采集、以及IP信譽庫這樣的方案，但這只是其中一個環節。在不談威脅感知、動態智能這樣的概念（瑞數也有）時，這個方案防機器人的步驟有四個：
1. 動態封裝，對網頁底層代碼做持續變幻，隱藏頁面中的表單信息、鏈接信息等，隱藏攻擊入口。這個步驟可以直接干掉56%的Bot（詳見Disktil報告）。
2. 動態取證，獲取包括客戶端指紋、用戶行為記錄等等信息，判斷發起請求的是人還是機器，兼容市面上99%（保守估計）的瀏覽器。
3. 動態混淆，使用一次性的加密算法對用戶發出的請求內容進行保護，有效阻止中間人攻擊，偽造請求、惡意代碼注入、竊聽或竄改等行為。
4. 動態令牌，通過對當前頁面內的合法請求地址授予一次性令牌，可保障攻擊者無法繞過業務邏輯發出非法請求，可有效防御越權、重放、Web Shell、應用層DDoS等。
再說一下部署：
1. 置於應用服務器前作為反向代理，支持所有主流應用服務器。
2. 不用改服務器哪怕一行代碼、一個配置，客戶端無須裝插件、控件。
3. 不基於特征識別和規則，％0誤阻斷，至於是否可能被繞過，我也不能說100%沒有漏網之魚。
4. 防護原理不依賴於海量大數據（如果有當然很好），用戶數據不會被傳到自己不可控的雲端（都在本地）。
5. 如果是移動APP，Native代碼需要集成SDK，HTML頁面可直接防御。
如果要問我說這功能靠不靠譜、性能行不行，我只能說沒經過測試你敢讓產品上線么？
另外如果要問我，算法被逆向了怎么辦，核心代碼又不在客戶端，Billion數量級別實時變幻的算法你去逆啊！
關於實現的技術難度，Idea也許很值錢，但在把它實現之前任何人都可以說這是自己的專利，其他公司做到了嗎？
利益相關：碰巧領了公司老板好幾個微信紅包
歡迎交流^_^