💡导读：你有没有想过，当你登录淘宝后，服务器是怎么记住你的？为什么关闭浏览器再打开，你依然处于登录状态？在黑客眼中，这些“登录凭证”就像是豪宅的钥匙。本期我们将深入身份认证机制的内部，看看JWT（JSON Web Token） 和Session 是如何被攻击者“偷走”或“伪造”的。
一、 身份认证的两大流派
在现代 Web 开发中，主要有两种方式来维持用户的登录状态：
1. Session + Cookie（传统派）
原理：
你输入账号密码登录。
服务器生成一个 Session ID（如
abc123），把它存在服务器的内存或数据库里，并把Set-Cookie: sessionid=abc123发给浏览器。下次你访问时，浏览器自动带上 Cookie，服务器查表确认
abc123对应的是谁。
痛点：服务器需要存每个人的 Session，用户多了服务器压力大（这就是分布式架构的噩梦）。
2. JWT（现代派 / 无状态）
原理：
登录成功后，服务器不存任何东西。
它签发一个Token（一串很长的字符串）给你，格式通常是：
Header.Payload.Signature。你每次请求都在 Header 里带上
Authorization: Bearer xxxxxx。服务器用密钥验证这个 Token 的签名是否正确，正确就放行。
优势：服务器无感，非常适合微服务。
二、 JWT 漏洞：当“通行证”可以被伪造
JWT 是目前最热门的攻击目标。因为一旦 JWT 被破解，攻击者就可以伪装成任何用户（包括管理员）。
1. 算法混淆攻击（Algorithm Confusion）
漏洞原理：JWT 支持多种算法。有的服务器配置不当，允许使用none算法（即无签名）。
正常 Token：
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWRtaW4ifQ.xxxxx攻击操作：用 Burp Suite 拦截，修改 Header 为：
json
{ "alg": "none", "typ": "JWT" }结果：删掉签名部分（Payload 后面的点及之后内容），发送给服务器。如果服务器接受了这个“无签名”的 Token，你就成功伪造了身份。
2. 空密钥或弱密钥（Weak Secret）
JWT 通常使用 HS256 算法，需要一个密钥（Secret）来签名。如果这个密钥是secret、123456或空字符串，那就完了。
实战工具：使用
john或hashcat破解 JWT 密钥。# 使用字典爆破 JWT 密钥 hashcat -a 0 -m 16500 jwt_token.txt wordlist.txt利用：拿到密钥后，你可以使用在线工具（如 jwt.io）随意修改 Payload（如
"role": "admin"），并重新签名。
三、 Session 漏洞：当“门禁卡”可以被预测
虽然 Session 老派，但坑也不少。
1. Session Fixation（会话固定）
原理：攻击者诱导受害者使用攻击者已知的 Session ID。
黑客访问网站，拿到一个 Session ID：
evil_session_123。黑客构造钓鱼链接：
https://bank.com/login?sessionid=evil_session_123。受害者点击链接并登录。
黑客使用
evil_session_123直接登录受害者的账户。
2. 会话注销不彻底
原理：用户点了“退出登录”，服务器只是清除了前端的 Cookie，但没有在后端销毁 Session。
结果：那个旧的 Session ID 依然有效，只要没过期，就能继续使用。
四、 OAuth 2.0 漏洞：第三方登录的陷阱
现在很多网站支持“微信登录”、“QQ登录”。这就是 OAuth 流程。
最常见的漏洞是redirect_uri 绕过。
攻击场景：
某网站授权 URL 是：
https://site.com/oauth?redirect_uri=https://site.com/callback。攻击者修改为：
https://site.com/oauth?redirect_uri=https://evil.com/callback。诱骗用户点击授权。
授权码（Code）被发送到攻击者的服务器
evil.com，攻击者用这个 Code 换取用户的 Access Token，从而接管账户。
五、 实战演练：修改 JWT 成为管理员
我们在OWASP Juice Shop 中进行实战：
注册普通用户并登录。
打开 Burp Suite，抓取请求，找到
Authorization: Bearer eyJ...头。复制 JWT Token 到 jwt.io。
观察 Payload 部分：
json
{ "data": { "id": 14, "email": "user@test.com", "role": "customer" }, "iat": 1700000000 }修改：将
"role": "customer"改为"role": "admin"。签名：如果服务器使用弱密钥（如
secret），在 jwt.io 的 Verify Signature 栏输入密钥，生成新的 Token。重放：在 Burp Repeater 中用新的 Token 替换旧 Token，访问
/rest/admin接口。结果：成功获取管理员权限，查看所有用户数据。
六、 2026 年防御建议
JWT 安全：
绝不使用
none算法。使用强密钥（大于 256 位），且定期轮换。
设置短有效期（Expiration Time），并使用 Refresh Token 机制。
Session 安全：
登录成功后强制更换 Session ID（防止固定攻击）。
退出登录时，务必在服务器端销毁 Session。
通用：开启 HttpOnly 和 Secure 属性，防止 XSS 偷 Cookie。
⚠️ 安全警示与法律红线
请务必遵守以下准则：
严禁账户接管：利用 JWT 伪造或 Session 绕过漏洞，登录他人账户（即使是测试账户），在渗透测试规范中也属于高风险操作，需谨慎授权。
敏感操作限制：在未获明确授权的情况下，严禁尝试修改他人的角色（如把自己提权为 Admin），这可能导致系统管理混乱，引发法律责任。
仅限靶场：本篇提到的所有攻击手法，请严格限制在Juice Shop、PortSwigger Web Security Academy 等合法靶场中练习。
身份即权限。拥有伪造身份的能力，意味着拥有毁灭信任体系的权力。请慎用这份力量。
💬 互动环节
你在开发中使用 Session 还是 JWT？为什么？
你遇到过最奇葩的登录逻辑是什么？（比如短信验证码直接显示在网页源码里？）
欢迎在评论区留言讨论！
👉 下一期预告：【漏洞攻防-前端篇】XSS 与 CSRF —— 当浏览器成为攻击者的“肉鸡”。
