91网首页-91网页版-91网在线观看-91网站免费观看-91网站永久视频-91网站在线播放

最近，朋友公司遇到了一件讓他們“寢食難安”的事：他們的短信驗證碼接口被人盯上了，充進去的錢沒多久就被刷得一分不剩。不充錢，業務直接受影響；但充錢吧，就像往無底洞里灌水。他們聯系短信服務商，對方反饋說可能是“被惡意盜刷”。由于他們沒自己的IT團隊，App是找外包做的，現在處于無人維護狀態。老板希望在不改代碼的前提下想個辦法幫忙止血。

斷癥：不是Bug，而是接口在裸奔

這個App已經穩定運行了兩年左右，程序 bug 的可能性比較小。我們懷疑是短信平臺信息泄露，或者接口被惡意程序利用。我上服務器看了下，他們部署非常簡單：前端用 Nginx 直接代理后端 Java 服務。打開 Nginx 日志發現有人以每秒3-6次的頻率請求獲取短信驗證碼的URL。并且接口調用未做二次驗證，這就等于把“發驗證碼”的權限完全開放了。哎！機會就這樣留給了別有用心的人。

亡羊補牢

這種情況，不改代碼確實有點難搞。從Nginx日志上可以看到，攻擊者使用了大量代理IP，每次請求的IP和參數都在變化，所以沒辦法通過IP黑名單的方式解決問題。我們只能寄希望于App在請求接口的時攜帶了攻擊者不具備的標識。由于Nginx無法直接打印完整請求頭，所以考慮用OpenResty通過Lua腳步把所有的請求頭內容輸出到日志里（這個接口是Get請求）。又只能在夜深人靜的時候加班學習，好在以前了解過一點OpenResty的知識。

分析請求頭

先折騰了一個簡單腳本來分析請求頭，要是這一關過不了，那基本可以放棄這個思路了。

location /api/reg/getCode {
    content_by_lua_block {
        for k, v in pairs(ngx.req.get_headers()) do
            ngx.say(k, ": ", v)
        end
    }
}

經過一番分析，發現App在每個請求上都帶上了一個版本號信息（雖然還在1.0.0），好在正好可以用來區分是否為惡意請求。

基于請求頭做驗證

接下來，就是利用 Nginx 的 map 指令判斷請求頭中是否包含指定版本號字段。命中放行，沒命中就攔下。
代碼如下：

http {
    map $http_app_version $allow {
        default 0;
        "~*xxx_1.0.0" 1;
    }
    server {
        listen 80;
        server_name xxx.xxx.com;
        location /api/reg/getCode {
            if ($allow = 0) {
                return 403;
            }
            proxy_pass http://java_service;
        }
    }
}

部署上去后看了下 Java 的日志，接口盜刷的請求直接被干掉，效果顯著。

以假亂真

雖然攔截成功，但返回403會暴露我們的防御策略，容易引起對手的注意，分分鐘就能突破這道薄弱的屏障。于是做了個升級：在nginx攔截到請求后，直接返回請求成功的響應結果，從此以后雙方都可以保持“成功”的假象。

改動如下：

location /api/reg/getCode {
    if ($allow = 0) {
        add_header Content-Type application/json;
        return 200 '{"code":"200","message":"驗證碼發送成功","success":true}';
    }
    proxy_pass http://java_service;
}

經測試，妥妥的，在不看日志的情況下，根本看不出到底有沒有真的請求到 Java 服務。

總結

一直不太能理解，這種攻擊到底圖個啥。既沒帶來直接利益，還要花成本搞代理搞腳本，這不是典型的損人不利己嗎。在之后的幾天里，一切又恢復到了往日的寧靜。雖然事情已經告一段落，但臨時止血不是長久之計，解決這類問題還是需加強程序安全驗證，提升攻擊難度。

最后

關于OpenResty，可以翻閱我的OpenResty學習筆記，歡迎點贊支持。