2011-09-30 23 views
2

我正处于一个Web应用程序的早期阶段,并且我已经达到了想要针对特定​​的安全问题做出最佳选择的程度。目前,HTML表单中的所有字段都是以它们所代表的数据库列命名的。因此,例如,如果在数据库中有一个名为“email”的字段,那么表单字段也会被称为“email”。这使得我的泛型代码更容易处理表单,但我自然而然地发现了这样一个名称的一个主要问题:它们可以让潜在的黑客洞察我的数据库是如何构建的,仅仅是查看源代码。如何防止表单变量名称泄露数据库结构?

我想到的主要解决方案包括加密字段名称,以便客户端永远不会有真正的。服务器端密钥将用于执行加密。不过,我担心这种做法可能会让事情变得更加复杂。例如:

  • 我可能会发现自己不得不更频繁地使用的帖子,作为加密的文本可能会更长,比原来的 - 推动GET的极限时,许多领域和他们的数据都存在。
  • 频繁的加密/解密调用可能会导致性能问题。我还没有测试过,所以最终可以忽略不计。
  • 非AJAX GETs不能使用这种方法,而不会看起来很神秘。

所以,我想知道你们对此的看法。我过度思考它,还是我在正确的轨道上?有更好的方法来处理它吗?顺便说一句,我也知道像“电子邮件”这样的字段名称并不能为开发者提供很多信息(为什么不使用txtEmail或类似的东西?)。我期待看看是否有一个很好的命名约定,我可以采用,因为它可能有助于解决上述问题。

+6

我想你已经在想这件事了。了解你的数据库结构并没有帮助。注意SQL注入攻击更重要。如果我可以注入一个选择语句到你的文章中,我得到了比你的模式更多的内容 –

+0

@LawMetzler谢谢 –

回答

7

如果任何人都可以通过SQL注入或任何其他方法获得对数据库的访问权限,则可以使用一个查询来显示您的模式,因此没有必要试图掩盖它。如果你觉得你不得不通过默默无闻的方式来实现安全性,那么你就没有做别的事情。

如果您的应用程序是安全的,那么潜在的攻击者是否认为他们知道您的架构并不重要。他们对这些信息无能为力。

我会花费更少的时间试图掩盖数据库(这只会让您和开发人员感到沮丧),并且会花更多时间试图锁定应用程序以防止潜在的注入攻击。

+1

太好了,谢谢!我只是想尽可能地做到彻底,加密领域的想法让我感到兴奋。毕竟,如果我能做些什么来帮助提高安全性,为什么不呢?你的文章有助于定义“为什么不”,这让我得出结论:没有必要。这个想法纯粹是为了补充现有的与安全相关的代码(包括SQL注入保护),在这种情况下,与我无关怀疑我现有的安全措施。 –

+1

我会通过指出知道数据库字段名称甚至是数据库结构使应用程序不太安全的想法,意味着通过这个想法,开源项目比闭源产品更安全当然是荒谬的。 –

+0

@JasonDean哈哈,非常好的一点。实际上使我的整个问题无效。哦,我想这个页面将永远帮助那些还没有达到那种认识的人。 –