导语：双因素认证（2FA）部署得再多，也挡不住逻辑漏洞。本文整理 13 种实战能用的 2FA 绕过手法，从最直接的响应篡改到隐蔽的会话劫持，每一条都源自真实漏洞案例。把这套清单跑一遍，市面上一半的 2FA 实现都能被攻破。
一、响应层的低级失误
这一类是渗透测试最先尝试的低垂果实，命中率最高，方法却最简单。
1.1 响应篡改
拿到 2FA 校验请求的响应包，直接把 "success": false 改成 "success": true，前端逻辑没做二次校验的话，直接放行进系统。
1.2 状态码操纵
返回包状态码是 4xx 系列，前端判断逻辑只看 HTTP 状态码。把 403 改成 200 OK，重放请求，就能绕过限制。
1.3 响应包泄露验证码
部分接口在响应包或注释里”贴心”地回显了 2FA 验证码本身。这种实现只能怪开发者太懒。
1.4 JS 文件分析
前端 JS 文件里有时会写死测试用验证码，或者暴露验证码生成逻辑。审计 JS 资源就能拿到 2FA code。
二、验证码本身的弱点
验证码本身如果设计不当，可以直接穷举或者复用。
2.1 验证码可重复使用
同一个 2FA 验证码没有失效机制，第一次用完还能再用来登录其他会话。这是逻辑漏洞里最常见的。
2.2 缺乏暴力破解防护
4 位、6 位纯数字验证码，没限速、没锁定、没图形验证码？那就直接写脚本跑，10 分钟内必然命中。
2.3 验证码完整性校验缺失
A 用户的 2FA 验证码可以在 B 用户的登录流程里使用。服务端没有做”验证码与用户绑定”的校验。
2.4 空值或固定值绕过
直接输入 000000 或者置空，部分老旧实现居然能过。永远不要假设用户会乖乖输入有效值。
三、关闭 2FA 的隐藏路径
与其攻破 2FA，不如想办法把它关掉。
3.1 关闭 2FA 的 CSRF（跨站请求伪造）
关闭 2FA 的接口没有 CSRF Token 保护，再加上一句”无需二次确认”，构造一个链接让已登录用户点一下，2FA 就被关掉了。
3.2 密码重置连带关闭 2FA
修改密码或者修改邮箱时，2FA 自动失效。这是历史包袱型漏洞，老系统的常见设计缺陷。
3.3 备份码滥用
备份码机制设计不严的情况下，攻击者可以利用备份码反推 2FA 重置流程，最终达到移除 2FA 限制的目的。前面所有思路都能套用一遍。
3.4 点击劫持关闭 2FA
用 iframe 套住关闭 2FA 的页面，再叠一层诱导按钮引诱受害者点击。受害者在不知情的情况下亲手关掉了自己的 2FA。
四、会话层的盲区
最隐蔽的一类——你已经绕过了，2FA 还在，但系统以为你是合法用户。
4.1 启用 2FA 不踢下线历史会话
用户原本的会话被劫持（XSS、会话固定等），后来才启用 2FA。但服务端没有让历史会话失效，新装的 2FA 形同虚设。
4.2 会话超时配置过宽
结合上一条，攻击者保持会话心跳，持续在线。受害者启动 2FA 之后，攻击者依然能用旧会话在系统里游走。
五、防御视角的红队建议
这 13 条不是教人作恶，而是给开发者的清醒剂。真正的防御要做到：
- 响应层：后端独立校验，禁用纯前端判断
- 验证码：用户绑定、单次失效、限速锁定、复杂度提升
- 关闭 2FA：CSRF Token + 二次确认 + 邮件通知
- 会话层：启用 2FA 必须踢下线全部历史会话，并设置合理的空闲超时
市面上的 2FA 实现，能同时扛住这 13 条检验的不超过两成。剩下八成，看的是没人去测，不是没人能打穿。
原文出处：本系列基于 harsh-bothra/learn365 仓库 day1 内容整理翻译。
暂无评论内容