就是想问问。
我有一个网站,每个用户都链接到数据库中的一个 ID,并且这个主键包含在许多表中。我提取用户信息的最快方法是拥有此 ID。
将此 ID 放在网站 HTML 代码中会被视为不好的做法吗?例如 id="theIDnumber"
否则我可以只使用用户名,然后在数据库中为这个 ID 引用它——这很好,但我相信使用 ID 会更快。
想法?
就是想问问。
我有一个网站,每个用户都链接到数据库中的一个 ID,并且这个主键包含在许多表中。我提取用户信息的最快方法是拥有此 ID。
将此 ID 放在网站 HTML 代码中会被视为不好的做法吗?例如 id="theIDnumber"
否则我可以只使用用户名,然后在数据库中为这个 ID 引用它——这很好,但我相信使用 ID 会更快。
想法?
我会说不,如果你的钥匙是可预测的。一个简单的例子:如果您使用顺序递增的主键,用户可以从可能涉及隐私问题的数据中提取信息。例如,他们可以推断出哪个帐户是在他们的帐户之前创建的。对于那些试图从您的网站系统地获取信息的人来说,生活也变得容易。
一些相关阅读
https://stackoverflow.com/a/7452072/781695
您让最终用户有机会处理这些变量并传递他们喜欢的任何数据。缓解此漏洞的对策是创建间接对象引用。这听起来像是一个很大的变化,但不一定非得如此。您不必重新设置所有表或任何东西的密钥,只需通过使用间接引用映射巧妙地处理数据即可。
https://security.stackexchange.com/a/33524/37949
隐藏数据库密钥并不是完全需要的,但如果攻击者试图在攻击中引用内部 ID,它确实会让生活变得更加困难。对文件名和其他此类内部标识符的直接引用可以让攻击者映射服务器的内部结构,这可能在其他攻击中很有用。这也引发了路径注入和目录遍历问题。
https://www.owasp.org/index.php/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet
对象引用映射首先由临时存储在会话中的授权值列表填充。当用户请求一个字段(例如:color=654321)时,应用程序会从会话中查找此映射以确定适当的列名。如果该有限映射中不存在该值,则用户未被授权。参考地图不应该是全局的(即包括所有可能的值),它们是临时地图/字典,只填充了授权值。