为什么数据库ID不能作为URL中的标识符

最近公司在进行网站的SEO优化,将所有主要页面的URL统一更改为新的格式,其中重要的一项改变是将所有URL的标识符统一为ID,例如过去我们的一个用户的公共页面URL是这样的

https://www.example.com/user/[:username]

而更新后的格式则变成

https://www.example.com/user/[:user_id]

在看到设计文档(Design Doc)的同时,我本能就对这个这样的URL形式产生了一丝疑虑,但又说不上为什么。

我们的用户信息是存在MySQL数据库的表单中,user_id是一个整数类型的主键(Primary Key),同时也是自增(Auto Increment)字段。

从安全角度来说,使用user_id来作为标识符的URL设计并没有什么问题,但是这样会有别的问题,什么样的问题呢?

暴露商业数据!

暴露的数据1:总体用户数量

有心人如果想要知道公司现在的总体用户数量,那么很简单,只需要注册一个新用户,然后查看自己的公共主页,这样新用户的user_id就会暴露出来,而这个user_id就约等于网站现在的总体用户数量(有一部分被删除的用户除外)

暴露的数据2:用户增速

如果说暴露总量还不是最危险的,用户增速则是更加重大的信息暴露。有心人知道URL中的user_id规律之后,可以通过做很简单的实验

1. 创建一个新用户,查看URL中的用户ID。 https://www.example.com/user/1000000

2. 隔一段时间之后(一周/月),再创建一个新用户,查看URL中的用户ID。https://www.example.com/user/1005000

二者相减(1005000-1000000)就可以轻易得到这段时间内的用户增长量。甚至可以在外部用很小的代价获得非常精确的用户增长曲线。

而这样的数据,对于大部分公司来说,都是非常核心的数据,尤其在公司未上市之前,应该尽量避免此类数据外流。

这样的情况十分普遍,因为在学习Web开发的初级教程中,几乎都会将数据库主键ID用来作为URL标识符,这样从URl解析主键到后台服务使用主键查询数据库,可以非常简洁直观。但是在实际的生产环境中,这样的做法往往并不可取。

那么有什么样的方法可以避免使用数据库ID呢?

1. 使用UUID —— UUID是乱序的字符串,所以无法用来预测数据,我们可以用多种方法来设计UUID。如果你使用了MongoDB等NoSQL的存储,那么恭喜你获得了天然的UUID,每一个ObjectID都是你可以使用的UUID。如果你的数据依然离不开关系数据库,那么可以考虑在数据库中扩增字段来生成UUID并存储,同时提供基于UUID的查询接口。

2. 加密自增ID —— 在系统已经到处使用自增ID作为内部查询的关键词的情况下,往往迁移到UUID会带来很大的工程开销,并且为了支持已有的URL访问,还需要维护两套不同的逻辑。在这种情况下一种相对简便的方法是在服务器端在生成URL的时候对于ID进行加密,这样在客户端看到的便是加密后的ID。当客户端进行请求的时候,服务器端再进行解密。这样的方法看似简单,其实其中也多需要注意的地方,比如加密的秘钥一旦泄露,便失去了意义。并且有在网页端动态生成URL的需求,也有不小的挑战。

(本文的部分观点源自 https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e