我被告知我不应该直接在Web应用程序的HTML代码中使用数据库ID.
目前,我在表格行ID(tableRow-454,其中454是数据库中行的ID),隐藏或选择表单或URL中的字段等内容上使用ID.(我不是指在页面上直观地告诉人们他们是####.)
我给出的建议是使用一些数学来模糊用户的ID.我认为这只会使事情变得更复杂并增加不必要的复杂性.但是我可以看到一些很好的理由让从HTML中确定数据库ID变得更加困难.
您是否对用户的ID进行了模糊处理？或者你在乎吗？
不,你只是为自己做额外的工作.
只要你做了足够的测试,在这里更改ID或者不会让用户访问他们不应该访问的内容,那么你就可以看到ID了.
在某些情况下,隐藏它们或具有非连续数字或者可能不从零开始计数可能是有益的.例如,如果有人获得3号订单,他们可能会开始提问...
IMO:不,你不应该混淆ID.如果安全性是您的应用程序的一个问题,那么无论如何都需要其他安全措施.默默无闻的安全是不够的,它只会给你一种虚假的安全感.
顺便说一句,如果你做一点点数学运算,那么其他身份证明 - 也可能是模糊的 - 仍然是可以预测的.在许多情况下,坏人不关心他闯入哪个账户,只要不是他自己的;-)
我会说它一般都可以,但有一些问题:
如果您的数字是连续的,您可以打开"猜猜游戏"(例如,用户更改详细信息？id = 4511 to details？id = 4512查看其他人的详细信息).要抵消这一点,首先需要适当的安全性.在某些情况下,这是不够的,因为揭示信息存在本身可能是一个问题.以Youtube为例,他们使用更多的传播ID:s以避免机器人屏幕刮擦.
如果您对id:s的性质做出假设,那么您可能会遇到麻烦(即,如果您直接在GUI中操作id:s或根据id对项目进行排序).一旦您需要对数据库进行负载平衡并最终得到单独的ID范围,这可能是一个令人讨厌的惊喜.
ID重用.例如,MySql:s InnoDB引擎在重启时重置序列(到最新的最大值).如果删除,这会让你很难受.
但所有这些问题也适用于自定义ID:s,但可能是这些人来自的地方.我眼中最灵活的解决方案是GUID:s,因为您可以在任何地方生成它们,并且不会遇到任何上述问题.虽然它们对人类来说更难阅读,所以这是一种权衡.
是的,你可能应该.
如果用户恶意更改了这些ID,您的代码是否会检查以确保他们当时请求的数据仍然是他们可以看到的数据？
隐藏ID比在整个地方手动执行验证更容易.
编辑,这次清晰:
如果您在屏幕上显示ID为1到20的列表,则可以非常轻松地验证响应是否在1到20之间.如果您将实际ID显示到屏幕,则需要花费内存缓存ID,或者需要进行另一次数据库调用/更长时间的查询以确保它们不会向您提供错误数据.
如果您使用代理ID,我认为这会变得更容易.
京公网安备 11010802040832号 | 京ICP备19059560号-6 