Language agnostic 我应该隐藏主键值吗？

我正在构建一个web应用程序，其中前端是一个高度专业化的搜索引擎。搜索是在主URL上进行的，当用户单击搜索结果以获得更详细的显示时，用户将被传递到子目录。此移交作为GET请求完成，主键在查询字符串中传递。我似乎记得在某个地方读到，向用户公开主键不是一个好主意，所以我决定实现可逆加密

---

我开始怀疑我是否只是在妄想。可逆加密（base64）可能很容易被任何愿意尝试的人破坏，使URL非常难看，而且比其他方式更长。我是否应该放弃加密并以明文形式发送主密钥？

只需发送主密钥即可。只要您的数据库操作与用户界面隔离，这就没有问题。

出于您的目的（构建搜索引擎），加密数据库主键的安全性权衡优势可以忽略不计。Base64编码不是加密——它通过隐蔽性实现了安全性，甚至不会对攻击者造成威胁

你所做的基本上是混淆。可逆加密（base64实际上不算加密）主键仍然是主键

你所阅读的内容可以归结为：你通常不希望你的主键在系统之外有任何意义。这称为技术主键，而不是自然主键。这就是为什么您可能会对患者ID使用自动编号字段，而不是SSN（称为自然主键）

技术主键通常比自然主键更受欢迎，因为看起来不变的东西会发生变化，这可能会导致问题。甚至国家也可以存在和消失

如果您确实拥有技术主键，那么您不希望通过赋予它们本来没有的含义而使它们成为事实上的自然主键。我认为在URL中放置主键是可以的，但安全性是一个单独的主题。如果有人可以更改该URL并访问他们不应该访问的内容，那么这是一个安全问题，需要通过身份验证和授权来处理

---

有些人会争辩说，用户永远不应该看到它们。我认为您不需要走那么远。

如果出于安全原因而隐藏主键，请不要这样做。这叫做默默无闻的安全，还有更好的方法。话虽如此，隐藏主键至少有一个合理的理由，那就是通过简单地检查URL中的查询字符串并确定他们可以简单地增加id值并下拉每个记录来防止有人删除您的所有内容。尽管你尽了最大的努力，一个坚定的刮刀可能仍然能够发现你的观察方法并做到这一点，但至少你没有让它变得容易。

如果你担心有人改变URL以尝试查看其他值，那么你可能需要查看令牌生成

例如，不是给用户一个“SearchID”值，而是给他们一个SearchToken，这是一个长的、唯一的psuedo随机值（Read:GUID），然后在内部映射到SearchID

---

当然，您还需要应用会话安全性和soforth，因为即使是具有非顺序ID的唯一URL也无法防止服务器和用户之间的任何嗅探

如果您试图保护数据库查询输入，只需使用参数化查询即可。如果主键被公众操纵，根本没有理由隐藏它们

---

当您在URL中看到base64时，您几乎可以肯定该站点的开发人员不知道他们在做什么，并且该站点易受攻击。

关于暴露主键的危险，您需要阅读Joshua Schachter的“”

包含标识符的URL将 让你失望的原因有三个

第一个是给定 一些物体，你可以找出 已创建对象的URL 围绕着它。这暴露了 数据库中的对象可能被删除 竞争对手或你可能认识的其他人 不希望获得此信息（如 盟国的著名证明 猜测德国坦克产量水平 通过查看序列号。）

第二，在某个时刻某个混蛋会 获得编写shell脚本的想法 使用for循环并尝试获取每个 系统中的单个对象；这 绝对没有乐趣

最后，对于用户来说，它 允许人们推导出某种类型的 社会等级制度。目睹了频繁的 劫持和/或黑客 高声望低数字ICQ ID

包含标识符的URL将 让你失望的原因有三个

错，错，错

首先，必须验证每个请求，不管它是以带有id的HTTP GET、POST或web服务调用的形式出现

第二，一个制作得当的网站需要防范依赖于IP地址跟踪和请求频率分析的僵尸程序；隐藏ID可能会阻止某些人编写shell脚本来获取一系列对象，但也有其他方法可以通过使用某种暴力攻击来利用网站

第三，ICQ ID很有价值，但这仅仅是因为它们与用户相关，是用户的主要身份识别手段；这是一种独一无二的用户身份验证方法，不被任何其他服务、程序或网站使用

---

总之。。是的，您需要担心刮刀、DDOS攻击、数据保护和其他一大堆问题，但隐藏ID并不能正确解决这些问题。

当我需要一个查询字符串参数来识别列中的一行时，我通常会在该表中添加一个GUID列，然后在连接st中传递GUID