伏羲智能决策 v0.1.1 将重点放在验证码系统的安全加固上。此次版本修复了内存泄漏、竞态条件和时钟攻击等 3 个高危安全问题，并加入三重频率限制防护。对任何包含登录、验证码或管理操作的系统来说，这些变化都比单纯增加业务功能更值得关注：攻击者往往会优先寻找认证链路中最容易被自动化利用的接口。
一次更新覆盖三类常见攻击面
从公开的版本摘要看，本次更新主要处理了三类问题。
1. 内存泄漏：验证码不是“用完即丢”这么简单
验证码通常会暂存在内存、缓存或会话存储中。如果生成和校验流程没有设置清理策略，长期运行的服务可能不断积累验证码、请求上下文或临时对象，最终表现为内存持续上涨、频繁 GC，甚至进程被操作系统终止。
一个稳妥的验证码生命周期至少应包含以下状态：
- 创建时间：限制验证码有效期。
- 尝试次数：避免同一个验证码被无限猜测。
- 使用状态：成功校验后立即失效。
- 清理时间：即使用户不再提交，也要删除过期数据。
如果验证码存储在 Redis 等外部缓存中，应设置 TTL；如果存储在进程内存中，则需要定期清理，并评估多实例部署下的数据一致性问题。
2. 竞态条件：校验和消费必须是一个原子动作
一个典型漏洞是：请求 A 和请求 B 几乎同时读取到同一个有效验证码，两个请求都通过校验，随后才分别删除验证码。对于登录、密码重置或高权限操作，这会把“一次性凭证”变成可并发重放的凭证。
正确思路不是简单地写成“先查询，再删除”，而是让校验、计数和消费尽可能由同一个原子操作完成。例如在 Redis 中使用 Lua 脚本，或者使用带条件的删除命令，确保只有一个请求能够成功消费验证码。
3. 时钟攻击：不要让响应时间泄露秘密
如果服务使用普通字符串比较验证码或令牌，比较过程可能在发现第一个不同字符后提前返回。攻击者通过大量请求测量响应时间，理论上可以逐步推断秘密内容。
对固定长度的令牌，应使用常量时间比较函数。需要注意的是，常量时间比较只能降低比较阶段的侧信道风险，并不能替代频率限制、验证码过期和失败锁定等控制措施。
三重频率限制应该分别限制什么
摘要提到新增“三重频率限制防护”。在实践中，三层限制可以分别对应不同的攻击维度，而不是简单地重复设置三个相同的阈值：
- IP 维度：限制单个来源地址的请求速率，拦截最直接的批量攻击。
- 账号或用户维度：限制针对同一个账号的尝试次数，避免攻击者轮换 IP 猛攻单一目标。
- 业务动作维度：对发送验证码、校验验证码、登录或重置密码等动作分别限速，避免攻击者绕过某一个接口的限制。
生产环境还需要考虑代理和负载均衡器带来的真实客户端 IP 识别问题。不能无条件信任用户提交的 X-Forwarded-For；只有在请求确实来自受信任代理时，才应读取并解析该字段。
一个可改造的验证码安全实现
下面是一个基于 Python 标准库的最小示例，用于演示三个关键点：过期时间、失败次数和常量时间比较。它不是完整的生产级验证码服务，示例中的内存字典只适合单进程演示；多实例部署时应替换为 Redis 等共享存储，并用原子操作完成“校验并消费”。
from dataclasses import dataclass
from secrets import choice
from string import digits
from threading import Lock
from time import time
from hmac import compare_digest
CODE_TTL_SECONDS = 300
MAX_ATTEMPTS = 5
@dataclass
class CaptchaRecord:
code: str
expires_at: float
attempts: int = 0
store: dict[str, CaptchaRecord] = {}
store_lock = Lock()
def create_captcha(subject: str) -> str:
code = "".join(choice(digits) for _ in range(6))
with store_lock:
store[subject] = CaptchaRecord(
code=code,
expires_at=time() + CODE_TTL_SECONDS,
)
return code
def verify_captcha(subject: str, submitted: str) -> bool:
now = time()
with store_lock:
record = store.get(subject)
if record is None or record.expires_at <= now:
store.pop(subject, None)
return False
record.attempts += 1
if record.attempts > MAX_ATTEMPTS:
store.pop(subject, None)
return False
valid = compare_digest(record.code, submitted)
if valid:
# 一次性消费：成功后立即删除
store.pop(subject, None)
return True
if record.attempts >= MAX_ATTEMPTS:
store.pop(subject, None)
return False
if __name__ == "__main__":
code = create_captcha("user-42")
print("demo code:", code)
print("wrong:", verify_captcha("user-42", "000000"))
print("right:", verify_captcha("user-42", code))
print("replay:", verify_captcha("user-42", code))
运行方式：
python captcha_demo.py
这个示例还有几个必须补齐的生产要求：
- 将
store替换为带 TTL 的共享缓存。 - 使用 Redis Lua 脚本或事务保证多实例环境下的原子校验与删除。
- 对 IP、账号和具体业务动作分别设置限流。
- 不在日志中记录完整验证码、密码或长期有效令牌。
- 对失败响应保持适度统一，避免暴露“账号是否存在”等信息。
- 为内存、请求量、失败率和缓存条目数量建立监控告警。
线上演示与安全验证建议
版本已经开放线上演示，但演示环境不应被当作生产系统直接使用。开发者在评估这类安全更新时，可以围绕下面的路径进行验证：
- 连续发送超过阈值的验证码请求，确认限制是否生效。
- 对同一验证码并发发起多个校验请求，确认最多只有一个请求成功。
- 等待验证码过期后重试，确认过期数据不会继续通过验证。
- 连续提交错误验证码，确认达到上限后凭证被废弃。
- 检查服务内存和缓存条目是否在长时间运行后持续增长。
- 对比不同输入长度或不同前缀的失败请求，确认没有明显的时间差异。
测试时不要使用真实密码、真实手机号或生产账号，也不要对公开演示环境进行高并发压测。若需要验证竞态条件，应在获得授权的本地或测试环境中进行。
采用建议：安全加固要落到可观测的控制面
v0.1.1 的价值不只是修复几个漏洞，而是提醒开发团队重新审视验证码这类“看起来很小”的接口。内存生命周期、并发一致性、侧信道防护和多层限流，必须共同构成认证链路的安全边界。
落地时可以用这份清单收尾：
- [ ] 验证码有明确 TTL，并能自动清理。
- [ ] 成功校验后立即消费，不能重复使用。
- [ ] 校验和消费在共享存储中具备原子性。
- [ ] 使用常量时间函数比较敏感令牌。
- [ ] IP、账号、业务动作三层限流均有明确阈值。
- [ ] 失败次数、内存、缓存和延迟都有监控。
- [ ] 演示账号、测试凭据与生产凭据完全隔离。
对于任何带有登录和高权限操作的系统，这些措施不是额外装饰，而是验证码功能能够安全运行的基本条件。