显然,取决于返回到Web前端的数据的类型/上下文(在我的情况下,设置是HTML / Javascript,.NET Csharp后端和JSON作为数据传输),如果我必须返回一个ID,例如如果消息是自动生成的主键(Int64),“隐藏”此真实ID的最佳方法是什么?
当然,对于大多数事情而言,我可以理解它并没有太大的区别,但是我正在开发的应用程序意味着,如果用户“猜测” URL中的ID以拉回另一条记录,则可能证明是安全的。问题..
关于方法,似乎有很多想法/评论,但是没有什么可以点击的。
我当时在考虑有一个自动生成的主INT,但也有一个辅助备用GUID。 GUID将返回到任何前端进程,并且当然自动生成的主ID仍将在后端中使用。
当然想到的是,GUID很难猜到/获得另一个人来访问记录?
人们有什么想法或最佳做法吗?
提前致谢,
大卫。
最佳答案
关于安全性,您有几个方面:
会话劫持
访问/修改/创建/删除用户无权记录
未经授权的访问
跨站点*攻击
中间人攻击
等等
解决这些问题的措施取决于您的体系结构和安全需求。
由于您对架构和安全需求的讨论不多,因此很难给出任何具体建议...
关于“ ID不可猜测”的一些要点:
“正确”的解决方案
一旦正确实施身份验证+身份验证,问题就消失了
因为正确实施了这两个步骤,确保只有经过身份验证的用户才能访问
一切,而且每个用户只能访问他被允许访问的内容。即使经过身份验证的用户知道某人的正确ID,也不允许他访问它,这将是安全的,因为他将阻止访问它。
“弱解决方案”
创建一个ConcurrentDictionary
作为线程安全的内存缓存,并将真实ID加上“临时ID”(例如,在第一次记录访问时刚生成的GUID)放在其中。您可以将该临时ID与某些特定于连接的方面(例如客户端IP,时间等)的盐和/或加密和/或哈希结合使用。然后,在每次访问时,您都要用ConcurrentDictionary进行检查并采取相应的措施...一个积极的效果:在应用程序重启(例如应用程序池回收)之后,同一条记录将获得不同的ID,因为这只是一个内存缓存这在网络农业中几乎不可用