1. 移动应用安全的全景图为什么WAF和JWT会同时出现在一个话题里字面上看WAF和JWT是两层完全不同的东西WAF工作在网络边界负责拦截恶意流量JWT是应用层的一种令牌格式负责身份认证。很多人习惯把它们分开学做完WAF配置就去做JWT实现做完JWT就以为自己把移动应用安全搞得差不多了。但实际做移动应用安全测试和防护的时候这两样东西是纠缠在一起的——一个典型的攻击者根本不会区分什么网络层、应用层他只会问一个问题这个App的认证体系能不能被打穿。而认证体系一旦被打穿WAF再强也拦不住合法令牌下的非法操作反过来如果JWT做得很完善但WAF形同虚设攻击者可以先通过注入类攻击直接拿下后端服务。所以真正做安全的人视野必须横跨这两层。这也是我写这篇东西的初衷。最近我在整理一个移动应用的安全加固方案涉及一个典型的移动端登录 后端API 管理后台三段式架构过程中把WAF绕过的常见手法、JWT token的设计与续签、以及两者之间的衔接问题都重新过了一遍。这篇文章不是教科书式的安全理论综述而是我在实际项目中遇到的问题、使用的方案、以及踩过之后的教训尽量用能直接复现的细节来讲。适合阅读这篇文章的人有三类第一类是正在做移动应用开发想把登录认证做得更扎实的后端或客户端工程师第二类是刚转行做安全测试想系统理解WAF和JWT到底怎么配合、怎么被攻击的测试人员第三类是像我一样做全栈或架构需要自己负责应用整体安全设计的人。无论你是哪一类我都建议你先放下对安全就是配个WAF的刻板印象——移动应用安全的核心问题永远是你的业务身份体系是否可信WAF只是外围的栅栏JWT才是门锁本身。先给一个整体视角。一个移动App从用户点击登录到请求业务数据安全链条大致是这样客户端发起登录请求经过WAF到达后端认证服务认证服务校验用户名密码后签发JWT token返回给客户端客户端后续请求在Header里携带JWT token再经过WAF到达业务API业务API先验证JWT的签名和有效期再执行具体业务逻辑。任何一个环节出问题整个链路就不可信了。所以接下来我按照实际工作中处理的顺序来讲先讲WAF的作用边界和绕过手法再讲JWT的签发与验证细节然后讲token续签和登出这两个最容易被忽视的设计死角最后把两者放在一个完整项目里做一次安全测试的实战复盘。2. WAF的边界感它能挡住什么挡不住什么WAF全称是Web Application Firewall名字里带防火墙三个字很多人下意识把它当成一个安全强边界认为流量过了WAF就安全了。这是移动应用安全里最大的认知误区。WAF本质上是一套规则匹配引擎它按照预设的规则集去检查HTTP请求的URL、请求头、请求体发现疑似SQL注入、XSS、命令注入等攻击特征就拦截掉。问题在于规则引擎永远存在两个短板一是规则覆盖不全总有不认识的攻击载荷二是规则会被各种编码、变形绕过。所以做移动应用安全第一件事就是搞清楚WAF的能力边界。2.1 WAF在移动应用架构里的典型部署位置移动应用和传统PC网站的流量特征有一个明显差异移动端请求的User-Agent更规整IP相对集中请求频率更受设备状态影响。这给WAF的部署和调优带来了一些特殊要求。我在项目里见到的常见部署方式有几种云WAF流量先经过云厂商的WAF节点再转发到源站。配置简单但要注意加白名单的问题——很多团队图省事直接在WAF里把移动端API路径全加了白名单结果等于没配WAF自建Nginx ModSecurity用开源WAF规则拦截灵活度高但规则更新和维护成本高误报率也更难控制网关内置WAF模块很多API网关比如Kong、APISIX、Spring Cloud Gateway的扩展自带WAF能力可以在微服务入口统一做安全校验。实际选型的时候我更推荐移动端专用的API走网关内置WAF或自建WAF而不是一股脑全部交给云WAF。原因是移动端API的流量模型非常固定且很多请求带签名、加密参数云WAF默认规则集不一定能正确解码这些参数反而容易产生误报——把正常业务请求拦了比被攻击更让人头疼。2.2 WAF绕过的常见手法与真实案例WAF绕过是安全测试里的必修课。我结合自己做过的一次移动端API安全测试来说。当时目标系统是某个App的后端API前面挂着一套商业WAF。我先做常规探测发现如下特征登录接口对参数有基础校验会拦截包含union select和