短信接口被刷爆:我用Nginx临时止血

打印 上一主题 下一主题

主题 1709|帖子 1709|积分 5127

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?立即注册

x
最近,朋友公司遇到了一件让他们“寝食难安”的事:他们的短信验证码接口被人盯上了,充进去的钱没多久就被刷得一分不剩。不充钱,业务直接受影响;但充钱吧,就像往无底洞里灌水。他们接洽短信服务商,对方反馈说可能是“被恶意盗刷”。由于他们没自己的IT团队,App是找外包做的,现在处于无人维护状态。老板盼望在不改代码的前提下想个办法帮忙止血。

断症:不是Bug,而是接口在裸奔

这个App已经稳定运行了两年左右,步调 bug 的可能性比较小。我们怀疑是短信平台信息泄露,或者接口被恶意步调利用。我上服务器看了下,他们部署非常简朴:前端用 Nginx 直接署理后端 Java 服务。打开 Nginx 日志发现有人以每秒3-6次的频率请求获取短信验证码的URL。而且接口调用未做二次验证,这就等于把“发验证码”的权限完全开放了。哎!机会就这样留给了别有效心的人。

亡羊补牢

这种情况,不改代码确实有点难搞。从Nginx日志上可以看到,攻击者利用了大量署理IP,每次请求的IP和参数都在变革,所以没办法通过IP黑名单的方式办理题目。我们只能寄盼望于App在请求接口的时携带了攻击者不具备的标识。由于Nginx无法直接打印完整请求头,所以考虑用OpenResty通过Lua脚步把所有的请求头内容输出到日志里(这个接口是Get请求)。又只能在夜深人静的时候加班学习,幸亏以前了解过一点OpenResty的知识。

分析请求头

先折腾了一个简朴脚本来分析请求头,要是这一关过不了,那基本可以放弃这个思路了。
  1. location /api/reg/getCode {
  2.     content_by_lua_block {
  3.         for k, v in pairs(ngx.req.get_headers()) do
  4.             ngx.say(k, ": ", v)
  5.         end
  6.     }
  7. }
复制代码
经过一番分析,发现App在每个请求上都带上了一个版本号信息(固然还在1.0.0),幸亏恰恰可以用来区分是否为恶意请求。

基于请求头做验证

接下来,就是利用 Nginx 的 map 指令判定请求头中是否包罗指定版本号字段。命中放行,没命中就拦下。
代码如下:
  1. http {
  2.     map $http_app_version $allow {
  3.         default 0;
  4.         "~*xxx_1.0.0" 1;
  5.     }
  6.     server {
  7.         listen 80;
  8.         server_name xxx.xxx.com;
  9.         location /api/reg/getCode {
  10.             if ($allow = 0) {
  11.                 return 403;
  12.             }
  13.             proxy_pass http://java_service;
  14.         }
  15.     }
  16. }
复制代码
部署上去后看了下 Java 的日志,接口盗刷的请求直接被干掉,结果显著。

以假乱真

固然拦截乐成,但返回403会暴露我们的防御战略,轻易引起对手的注意,分分钟就能突破这道薄弱的屏蔽。于是做了个升级:在nginx拦截到请求后,直接返回请求乐成的相应结果,以后以后双方都可以保持“乐成”的假象。
改动如下:
  1. location /api/reg/getCode {
  2.     if ($allow = 0) {
  3.         add_header Content-Type application/json;
  4.         return 200 '{"code":"200","message":"验证码发送成功","success":true}';
  5.     }
  6.     proxy_pass http://java_service;
  7. }
复制代码
经测试,妥妥的,在不看日志的情况下,根本看不出到底有没有真的请求到 Java 服务。

总结

不停不太能明白,这种攻击到底图个啥。既没带来直接长处,还要花成本搞署理搞脚本,这不是典型的损人不利己吗。在之后的几天里,齐备又恢复到了往日的宁静。固然事情已经告一段落,但临时止血不是长久之计,办理这类题目还是需加强步调安全验证,提拔攻击难度。

最后

关于OpenResty,可以翻阅我的OpenResty学习笔记,接待点赞支持。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

勿忘初心做自己

论坛元老
这个人很懒什么都没写!
快速回复 返回顶部 返回列表