马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?立即注册
x
最近,朋友公司遇到了一件让他们“寝食难安”的事:他们的短信验证码接口被人盯上了,充进去的钱没多久就被刷得一分不剩。不充钱,业务直接受影响;但充钱吧,就像往无底洞里灌水。他们接洽短信服务商,对方反馈说可能是“被恶意盗刷”。由于他们没自己的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学习笔记,接待点赞支持。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |