ihmily

交易的对手从来都不是别人，而是自己的内心。

遇到过很多这种，比如之前遇到有一男一女带着 10-15 岁左右的女孩，说钱包丢了，小孩两天没吃饭了，能不能帮助一下给点饭钱让小孩吃饭，那一男一女看我在犹豫，还拉着那女孩让她叫我哥哥并说求求你了...

还有就是从小到大看到无数次，看着像女大或者女高中生那种（有些看着像学生装），蹲在那，面前摆张卡纸，纸上写着 xxx 困难（要饭钱/车钱），她们共同特征是 都披着头发都散下来，看不到脸 (ˉ▽ˉ；)...

这个我要吐槽一下 iPhone ，电信、联通和移动，用哪个运营商都一样，和朋友一起在动车上，他在旁边用 Android 手机随便刷抖音，我却连微信消息都发不出去，大部分时间都是在重连...啥都不错，信号这方面真就不敢恭维了。

这博客看的好舒服，排版很棒，写的很用心，照片拍的好！

@hackerwgf

>哎，曾经很骄傲可以从一堆下载中找到真实的下载按钮

死去的回忆突然攻击我 :)

另外, 双 token 比单 Token 也有利于日志分析：

检测到 access_token 异常 → 可能是网络攻击
检测到 refresh_token 异常 → 可能是账户被盗


场景 A：Access Token 被重复使用, 重放攻击
时间线：
T0: 用户请求 GET /workflows ，Access Token 在网络中传输
T1: 攻击者在网络中拦截到这个 Access Token
T2: 攻击者立即用这个 Access Token 发起请求
T3: 15 分钟内，Access Token 仍然有效 → 攻击成功

# 日志中看到：
- 同一个 Access Token 来自不同 IP
- 同一个 Access Token 在短时间内高频使用
- User-Agent 不一致

影响范围： 相对局部（只影响当前 token 时间窗口）



# 场景 B：Refresh Token 被重复使用
时间线：
T0: 用户登录，得到 RT_1 ，存储在 localStorage
T1: 攻击者通过某种方式窃取了 RT_1 （钓鱼、数据库泄露、恶意软件等）
T2: 用户的浏览器自动刷新，用 RT_1 → 得到 RT_2 ，RT_1 进黑名单
T3: 攻击者尝试用 RT_1 刷新 → ❌ 触发第 133-135 行的检测


而如果是单 token ，则无法区分是哪种场景导致的黑名单 Token 被重复使用

单 Token 重复使用的多种可能性. 有可能是
1.并发刷新（正常行为）
用户打开页面，5 个 API 同时发起：
──────────────────────────────────────
T0: 5 个请求都带着过期的 token_v1
T1: 5 个请求都返回 401
T2: 5 个响应拦截器同时触发刷新
- 请求 1: POST /refresh { token: token_v1 } → 成功，返回 token_v2 ，token_v1 进黑名单
- 请求 2: POST /refresh { token: token_v1 } → ❌ 黑名单检测触发
- 请求 3-10: 同样被拒绝

2.多 Tab/多窗口（正常行为）
用户同时打开多个 Tab：
──────────────────────────────────────
Tab A: 用户正在浏览，token 刚好过期
Tab B: 用户也在操作，同一个 token 过期

Tab A 先刷新：
POST /refresh { token: token_v1 } → 成功，token_v1 进黑名单
localStorage.setItem('token', token_v2)

Tab B 延迟几秒刷新（还没来得及读取新 token ）：
POST /refresh { token: token_v1 } → ❌ 黑名单检测触发

# 后端日志：
# 以上问题检测到 token_v1 被重复使用，但不能确定是不是网络攻击！


3.账户被盗（异常行为
真正的攻击场景：
──────────────────────────────────────
T0: 攻击者窃取了 token_v1
T1: 合法用户刷新：POST /refresh { token: token_v1 } → token_v2 ，token_v1 进黑名单
T2: 攻击者尝试刷新：POST /refresh { token: token_v1 } → ❌ 黑名单检测触发

# 后端日志：
# 检测到 token_v1 被重复使用
# 这次是真的攻击！

问题 1：

单 Token 方案：同一个 token 既用于访问又用于刷新

问题场景：
用户在 Tab A 刷新了 token ，得到 token_v2
用户在 Tab B 仍然持有 token_v1
Tab B 的请求会失败（因为 token_v1 已在黑名单），无法刷新
需要复杂的跨 Tab 同步机制


问题 2：
单 Access Token 的暴露场景：
每个 API 请求的 HTTP Header 中
浏览器开发者工具的 Network 面板
可能被记录在服务器日志中
可能通过中间代理服务器
如果有 XSS 漏洞，容易被窃取

假设你每天发送 1000 个请求 → Access Token 暴露了 1000 次，用作刷新 token 不安全


而双 token 中 Refresh Token 仅在以下情况使用：
✅ Access Token 过期时（比如每 8 小时一次）
✅ 只发送到特定的刷新接口
✅ 不会出现在普通业务请求中


虽然 Refresh Token 也有被窃取的风险，但是风险小很多

云 GPU 可以试试 Autodl: https://www.autodl.com/

12 月了，一年又见底了，大家都过得怎样呢？

2025： https://www.v2ex.com/t/1176131
2024： https://www.v2ex.com/t/1094197
2023： https://www.v2ex.com/t/996699

顺便回顾了一下往年帖子，算是每年的年终总结吗，我认为是很有意思的记录。