20260526 - 关于已经修复的 404 bug 的具体原因

[Livid]

假设有恶意程序写一个简单的循环，持续访问不存在的 topic id ，那么每次 V2EX 接收到这样的请求，还需要从数据库里查了之后，才知道是无效的 topic id ，这个查询过程就会很浪费资源。

所以程序中有这样的一种机制，如果 topic id 明显大于某个值，那么就不用查任何数据库资源，直接返回 404 。

这个值应该是被定期更新并且加上一个足够大的安全值。

但是由于最近测试服里的一个 bug ，导致这个值自从测试服上线之后，就一直没有被正确更新。因此当 topic id 持续增长，终于来到旧值 + 安全值的边界时，所有新的 topic id 就都 404 跳转了。

这个问题的根源是测试服上更新全站统计数据进 Memcached Key 时的 bug ，这个 bug 现在已经修复（测试服在这个地方现在使用了单独的 Memcached Key ）。

[aheadlead]

没想到竟然是一个这样简单的问题..

[InDom]

啊?

[povsister]

我这类似用途是靠 id 算法，全局时间+safe margin 搞的。通过当前时间+id 编码规则就能很容易初步判定 id 是不是伪造的。后面被枚举刷太狠了就又在回源套了层布隆，也是时间校验，安全值范围内允许回源否则一律拦截。

最开始考虑过全局通过有状态存储维护这个上限，但组件太多依赖一个单点就很麻烦。

[Pipecraft]

那现在已经公开秘密了，这个机制似乎不能防止恶意程序了。

[ByteRan]

有点像千年虫的 BUG

[zhouzoki]

现在应该有更好的方法了吧

[MFWT]

@Pipecraft 应该也不追求完全拦住吧，至少抬高一点门槛

[Livid]

@Pipecraft 很可能这个机制现在也是不需要的。

一些这样的逻辑都是当年应对某些恶意访问时写的。

然后年复一年这样的逻辑堆太多，本身也是一种问题。

[itechify]

哈哈哈哈哈，这也能宕机一天。历史遗留的 feature ，堆积的临时性代码，可以考虑做下减法了🤣

[tty0]

可不可以将 ID 改为编码?
先校验自定义编码是否有效, 有效再去查询数据库.

[JoeJoeJoe]

哈哈哈哈 这是有历史沉淀的站点才能出现的问题😂

[Tink]

这个机制感觉可以考虑用别的算法替代掉

[GeorgeV]

v 站的这个 feature 很有趣，时不时来一下也蛮好的

[Ketteiron]

@zhouzoki #6 可以借鉴 b 站当初从数字改成数字字母，或者用算法，或者给数字加个 token ，例如 /t/12345 -> /t/12345/fuawf67adafjmaiowf 。不过对于 V2EX 这种有年头的网站，重构的收益有些低。

[CEBBCAT]

> 假设有恶意程序写一个简单的循环，持续访问不存在的 topic id
似乎是缓存穿透，如果是恶意请求，那就是 CC 攻击？

听起来似乎是判定逻辑直接使用了缓存中存储的 topic count 作为 max id ？也许可以在新发帖时主动向 Cache 推送 max id ，记得使用 CAS 原子操作

BTW Livid 你最后一段似乎语序有些模糊，是这个 bug 让你措手不及吗？注意休息

[ryd994]

@CEBBCAT #15 不用 CAS ，因为这个值不需要太精确。加个安全余量即可。同一时间生成的新帖 ID 应该差不了多少。

[tf2]

这个 idea 其实很好。不过可以做得细致一点

故意设置一些不存在的但是红线主题 id

谁访问，封谁的 IP

[diudiuu]

挺好的这个想法
现在换个算法，可能以前的数据就难受了，最后全是补丁

[yougg]

可以通过 ULID 或者 UUID v7 判断时间戳

[ovtfkw]

缓存穿透吗，但是现在的主题 id 都是线性增加的，很容易被猜到把，那直接恶意大量访问已经存在的主题呢