在URL中公开DB内部ID是不好的做法吗?

时间:2012-03-28 09:12:44

标签: java database url web obfuscation

在URL中公开数据库内部ID是不好的做法吗?

例如,假设我有一个users表,每行有一些ID(主键)。公开网址myapp.com/accountInfo.html?userId=5,其中5是一个真正的主键,会被视为“坏事”,为什么会这样?

还假设我们正确防御SQL注入。

我最感兴趣的是与Java Web技术堆栈相关的答案(因此是java标签),但一般答案也会非常有用。

感谢。

5 个答案:

答案 0 :(得分:7)

这取决于您解析URL的方式。如果允许盲目的SQL注入是不好的。您只需要从用户输入验证id。

如您在地址栏中看到的那样,Stackexchange还会将行的ID放入URL中。诀窍是解析部分并获得所有可能的SQL。简单的方法是检查id是否为数字。

答案 1 :(得分:7)

在URL中传递并不是一件坏事,因为它对最终用户没有太大意义 - 如果你在运行应用程序时依赖于该值,那么它就是唯一的错误。例如,您不希望用户注意到userId = 5并将其更改为userID = 10以显示另一个人的帐户。

将此信息存储在服务器上的会话中会更安全。例如,当用户登录时,其userID值存储在服务器上的会话中,并且每当查询数据库时都使用此值。如果你这样做,通常不需要传递URL中的userID,但是它不会受到影响,因为它不会被你的DB查询代码使用。

答案 2 :(得分:3)

是的,这是件坏事。您正在公开实现细节。多么糟糕?那要看。它会强制您对用户输入执行不必要的检查。如果其他应用程序依赖于它,则您不再可以自由更改数据库方案。

答案 3 :(得分:0)

在URL中使用数据库ID是好的,因为这个ID永远不会在对象(db rows)生命中发生变化。因此,URL是持久的 - 这是URL最重要的方面。另请参阅Cool URIs don't change

答案 4 :(得分:0)

PKs适用于该系统 对于用户来说,它可能代表不同的含义:
对于例如 让我们考虑以下链接。使用主键,它显示产品
productA,productB,productC下的项目;

(A) http://blahblahsite.com/browse/productA/111(pkey)
  (B) http://blahblahsite.com/browse/productB/112(pkey)
  (C) http://blahblahsite.com/browse/productC/113(pkey)
链接 B 上的用户可能会觉得ProductB下有112个项目,这会产生误导。

同时它会在合并表时引起问题,因为PK会自动递增。