运营中心客户端：毫秒响应，交互如呼吸

　　去年冬天那会儿，运营中心客户端刚上线，运维组老张半夜三点在群里@全员，说监控大屏突然卡成PPT——页面加载十八秒，点击按钮没反应，等反应过来已经错过三个告警。我当时刚把娃哄睡，抱着笔记本在沙发上翻日志，发现WAF规则库里多了条没见过的XSS拦截记录，IP是内网某台测试机的，但那台机子三天前就下线了。我原以为又是哪个实习生手滑，结果查监控发现，攻击流量是从运营中心客户端发出来的——对，就是那个号称“毫秒响应”的客户端。

　　第二天开复盘会，安全组小李拍桌子：“这客户端的API接口连基本的CSRF Token都没校验！”我翻他白眼：“有Token就能防住？上周刚有个马儿绕过Token拿下了财务系统。”他不服，非说“那是他们WAF没调好”。我懒得跟他争，直接调出客户端的请求日志——三百多条重复POST，每条间隔十二毫秒，参数里嵌着base64编码的shellcode。最绝的是，这些请求的User-Agent全写着“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36”，跟正常用户一模一样。小李盯着屏幕看了半分钟，憋出一句：“这他妈是自动化工具？”我点头：“对，而且跑在客户端本地。”

　　后来查出来，是前端代码里硬编码了测试环境的API地址，打包时没删干净。攻击者扫到这个地址，直接用客户端当跳板，把恶意请求伪装成正常流量发出去。老张在旁边补刀：“我说怎么昨天服务器上多了个/tmp/.ssh/authorized_keys文件，原来是这孙子想反向连接。”我翻了下文件时间戳，正好是客户端卡顿那会儿——攻击者估计在试密码，结果触发WAF的频率限制，把正常用户的请求也给堵了。

　　但最让我意外的是，客户端的“毫秒响应”反而成了安全漏洞的帮凶。因为前端把所有交互都做成了异步请求，用户点击按钮后，客户端立刻返回“操作成功”，实际请求还在后台跑。攻击者利用这个时间差，在用户无感知的情况下发了三百多次请求——如果客户端像传统系统那样，每次操作都等服务器返回再更新界面，攻击者根本没机会发这么多请求。我原以为“流畅交互”是优点，结果成了安全成本。

　　后来我们改了策略：客户端只做展示，所有敏感操作必须跳转到内网门户，而且加上了二次认证。小李还非要给API接口加JWT，我说“加JWT不如加频率限制”——上周刚有个案例，攻击者用偷来的JWT token刷爆了数据库。他不服，说“JWT是标准”。我直接调出日志：“看，这个IP昨天用JWT刷了两千次登录接口，token都没变。”他盯着屏幕看了十秒，转身去改频率限制规则了。

　　现在回头看，运营中心客户端的“毫秒响应”和“交互如呼吸”，本质是把安全成本转嫁给了用户——用流畅的体验掩盖了背后的风险。老张说“用户喜欢快”，我说“用户更喜欢不被盗号”。上周有个客户打电话，说他们的运营账号被用来发垃圾邮件，我一查，又是客户端的API接口被扫出来了。这次攻击者更聪明，没直接发请求，而是先通过客户端的漏洞拿了session，再用session去调接口——WAF连拦截记录都没留，因为流量看起来完全正常。

文章配图，仅供参考

　　昨天小李又来找我，说“客户投诉客户端太卡”。我翻了下监控，平均响应时间三百毫秒，比之前慢了十倍。他说“是不是频率限制太严了？”，我指了指日志：“看，攻击流量降了九十%，正常用户的请求全通过了。”他愣了下，说“那为什么还卡？”。我笑了：“因为现在所有操作都要等服务器返回，用户得适应‘不流畅’的交互——但至少，他们的账号安全了。”

　　现在我还在等，等客户什么时候能明白：安全从来不是免费的，那些“毫秒响应”的流畅，都是用被攻击的风险换来的。至于“交互如呼吸”？呼吸太顺畅了，容易让人忘了屏住呼吸——而安全，有时候就得学会屏住呼吸。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!