我读过在URL中使用数据库密钥是一件不好的事情。

例如，

我的表格有3个栏位：「ID：int」，「标题：nvarchar(5)」，「Description：Text」

我想创建一个显示记录的页面。就像是 ...

http://server/viewitem.aspx?id=1234

• 首先，有人可以详细说明为什么这是一件坏事吗？
• 其次，有哪些方法可以解决在URL中使用主键的问题？

解决方案

回答

有时这有点花哨，但我们想为事物使用唯一的业务标识符，而不是代理键。

它可以像ItemNumber一样简单，而不是Id。

Id是数据库问题，而不是业务/用户问题。

回答

我认为在URL中使用主键是完全合理的。

但是，一些注意事项：

1)避免SQL注入攻击。如果我们只是盲目接受id URL参数的值并将其传递给数据库，则可能会遇到危险。确保清理输入内容，使其与我们所拥有的键的任何格式匹配(例如，去除所有非数字字符)。

2)SEO。如果网址包含有关商品的上下文信息(例如，"蓬松的大兔子"而不是1234)，则有帮助。这有助于搜索引擎查看页面是否相关。它对用户也很有用(我可以从浏览器的历史记录中看出哪个记录​​是哪个记录，而不必记住数字)。

回答

本质上不是一件坏事，但有一些警告。

注意事项之一是，有人可以键入不同的键，并且可能提取我们不希望/期望他们获得的数据。我们可以通过增加密钥空间来减少此操作成功的可能性(例如，使ids随机为64位数字)。

第二个警告是，如果我们正在运行公共服务并且有竞争对手，那么如果它们是单调的，他们可能能够从密钥中提取业务信息。示例：今天创建一个帖子，一周内创建一个帖子，比较ID，我们已经提取了发布帖子的速度。

警告三是它易于受到SQL注入攻击。但是你永远不会犯那些错误，对吗？

回答

• 在URL中使用整数主键存在安全风险。有人使用任何数字发布都非常容易。例如，通过正常的Web应用程序使用，用户创建ID为45(viewitem / id / 45)的用户记录。这意味着用户会自动知道还有44个其他用户。并且除非我们有正确的授权系统，否则他们可以通过创建自己的URL(viewitem / id / 32)来查看其他用户的信息。

2a。使用适当的授权。
2b。使用GUID作为主键。

回答

显示密钥本身并没有本质上的坏处，因为它没有真正的意义，但是显示获取对某项的访问权限的方法是不好的。

例如，假设我们有一家在线商店，该商店出售了2个商家的商品。商家A有项目(1、3、5、7)，而商家B有项目(2、4、5、8)。

如果我在商人A的网站上购物，请参阅：
http：//server/viewitem.aspx？id = 1

然后，我可以尝试摆弄它并输入：
http：//server/viewitem.aspx？id = 2

这可能使我可以访问我不应该访问的商品，因为我正在与商人A而不是商人B一起购物。通常，允许用户摆弄诸如此类的东西可能会导致安全问题。另一个简短的示例是员工，他们可以查看其个人信息(id = 382)，但他们键入其他人的ID即可直接转到其他人的个人资料。

话虽如此，但只要在系统中内置安全检查以确保人们在做应做的事情(例如：不与其他商人购物或者不查看其他雇员)，这还不错。

一种机制是在会话中存储信息，但有些机制则不这样。我不是网络程序员，所以我不会再讨论了:)

最主要的是确保系统安全。永远不要信任从用户返回的数据。

回答

在URL中使用ID不一定是不好的。尽管由专业人员完成，但该站点仍在使用它。

他们怎么会有危险？当允许用户更新或者删除属于他们的条目时，开发人员会实施某种身份验证，但他们通常会忘记检查条目是否确实属于我们。当恶意用户注意到" 12345"属于我们时，可能会形成一个URL，例如"" / questions / 12345 / delete"，然后将其删除。

程序员在执行此操作之前，应确保具有任意ID的数据库条目确实属于当前登录用户。

有时，有充分的理由要避免在URL中公开ID。在这种情况下，开发人员通常会为每个条目生成存储的随机哈希，并在URL中使用这些哈希。恶意篡改URL栏中的人将很难猜测属于其他用户的哈希。

回答

安全和隐私是避免这样做的主要原因。泄露数据结构的任何信息都是黑客可以用来访问数据库的更多信息。正如mopoke所说，我们还使自己遭受了SQL注入攻击，这种攻击相当普遍，并且可能对数据库和应用程序极为有害。从隐私的角度来看，如果我们要显示任何敏感或者个人信息，那么任何人都可以用数字代替信息来获取信息，并且如果我们没有身份验证机制，则可能会使信息面临风险。另外，如果查询数据库很容易，我们就会遇到一个拒绝服务攻击的攻击者，因为有人知道每个人都会得到响应，因此他们只对服务器循环访问URL。

无论数据的性质如何，我都建议不要在URL中共享任何可能泄露应用程序体系结构的内容，在我看来，这只是在惹麻烦(对于隐藏字段，我有同感，但并非如此)真的隐藏了)。

为了解决这个问题，我们先对参数进行加密，然后再传递它们。在某些情况下，加密的URL还包括某种形式的验证/身份验证机制，以便服务器可以确定是否可以处理。

当然，每个应用程序都是不同的，并且要实现的安全级别必须与功能，预算，性能等保持平衡。但是，对于数据安全性，我偏执狂并没有什么错。

回答

似乎每个人都在使用这种技术发布"问题"，但是我还没有看到任何解决方案。有什么选择。 URL中必须有一些内容可以唯一定义要向用户显示的内容。我能想到的唯一其他解决方案是从表单运行整个网站，并让浏览器将值发布到服务器。由于所有链接都需要提交表单，因此编码起来有些麻烦。而且，网站用户输入他们想要的任何值仅极少困难。同样，这也不允许用户对任何内容添加书签，这是一个主要缺点。

@John Virgolino提到了加密整个查询字符串，这可以帮助完成此过程。但是，对于大多数应用程序来说似乎有点过头了。

回答

我一直在阅读有关此内容，寻找解决方案，但是正如@Kibbee所说，目前尚无真正共识。

我可以想到一些可能的解决方案：

1)如果表使用整数键(可能)，请在标识符中添加一个校验和数字。这样，(简单)注入攻击通常将失败。收到请求后，只需删除校验和数字，然后检查校验和数字是否仍然匹配，然后我们便知道URL已被篡改。这种方法还隐藏了"增长率"(某种程度上)。

2)最初存储数据库记录时，请保存一个"辅助密钥"或者我们愿意成为公共ID的值。这必须是唯一的，通常不是连续的示例是UUID / Guid或者整数ID的哈希(MD5)，例如http：//server/item.aspx？id = AbD3sTGgxkjero(但请注意与http不兼容的字符)。 Nb。第二个字段将需要建立索引，我们将失去在1)中获得群集的好处。