最近，朋友公司遇到了一件让他们“寝食难安”的事：他们的短信验证码接口被人盯上了，充进去的钱没多久就被刷得一分不剩。不充钱，业务直接受影响；但充钱吧，就像往无底洞里灌水。他们联系短信服务商，对方反馈说可能是“被恶意盗刷”。由于他们没自己的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 服务。
总结
一直不太能理解，这种攻击到底图个啥。既没带来直接利益，还要花成本搞代理搞脚本，这不是典型的损人不利己吗。在之后的几天里，一切又恢复到了往日的宁静。虽然事情已经告一段落，但临时止血不是长久之计，解决这类问题还是需加强程序安全验证，提升攻击难度。
推荐本站淘宝优惠价购买喜欢的宝贝:
本文链接：https://zblog.hqyman.cn/post/10435.html 非本站原创文章欢迎转载，原创文章需保留本站地址！
微信支付宝扫一扫，打赏作者吧～休息一下~~
萌ICP备20248119号
