通常如何在JAR文件中实现安全的数据库连接？

Question

我不是Java开发人员，但我的客户已经雇佣了一个人来更新他们网站上的一些JAR文件。在此之前，我们审核了现有的代码并发现了一些安全漏洞。我们用来使文件更安全的解决方案之一是创建一个新的数据库用户，该用户对数据库具有只读访问权限，并且只对那些需要JAR文件操作的表创建。然后，我发现他们将这些证书以JAR文件的形式存储在纯文本文件中，只是远离公众的教育猜测。最后，今天他们要求更宽松的数据库特权，但我不认为她理解她真的不应该需要它们来获得正确书写的JAR文件。

无论如何，我敢肯定，这个开发者不知道一个安全漏洞，如果它在背面咬着。我不知道有足够的了解的Java/JAR文件才能正常劝她什么，她应该做，只有足够的了解信息安全告诉她什么，她不应做。

所以写一个连接到远程MySQL数据库的分布式JAR文件时有哪些典型的安全注意事项？有没有一种标准的方式来加密连接细节（用户名和/或密码）？ IIRC，是不是.jar文件只是赞美ZIP压缩文件，并不能解压文件和查看源代码中的连接细节？有没有加密jar文件内容的方法？

---

更新：我收到了以下开发者的澄清。这听起来正确吗？

所有jar文件中的类encrypoted。在将它们归档到jar文件之前，我总是加密所有的类文件。如果你打开任何[压缩]的jar，你只会看到加密的代码。因此用户无法通过反编译来查看源代码。类使用jdbc连接到数据库，搜索eangine需要连接到数据库以运行sqls。这些sqls位于jar文件中的加密分类中。

当我问你关于加密DB密码的问题时，我的意思是你在下面说的。我们将在java中编写加密/解密代码并使用它。作为reoutine类加密过程的一部分，源代码中的编译类将再次得到加密。我们使用称为Retroguard的Java混淆工具来加密所有的类。我们还在html页面中嵌入了一个关键字，以确保该应用程序仅在从[redacted]网站下载的情况下才能使用。如果用户将jar复制到本地机器并尝试运行它，它将会失败。

Answer 1

是的，JAR只是ZIP文件，所以完全可以使用WinZip打开一个并查看内容。如果你知道你在做什么，你可以在里面找到一个纯文本密码。

听起来像您的JAR包含一个直接连接到数据库的客户端。您不会说这是通过Internet还是通过VPN或LAN完成的。数据库是否从客户端远程部署？

这就是为什么客户端/服务器应用程序去的时候，很难通过互联网将其固定。

您的应用听起来像我的经典客户端服务器。我有这个权利吗？

中间层通常是在客户端和数据库之间引入以检查安全性，验证并绑定投入，穿梭请求到相应的处理程序实现。让用户在将它们传递给数据库之前提供中间层必须验证的凭据。

它也可以给你一个打击SQL注入攻击的机会。

如果你加密JAR内容你必须编写自定义的类装载器装载的时候对其进行解密。不是因为心灵的隐隐。

如果你的客户是一个Swing应用程序，配合内置到每个组件注册的监听器和事件处理程序的所有逻辑和数据库的东西，你必须在你的手中了严重的重写。您将转向更多面向服务的体系结构，其中所有工作都由服务器端的服务完成。客户端只做它在传统MVC中应该做的事情：将事件传递到服务器端并显示结果。你的客户会轻很多。

这将成为您的开发团队和业务最大的震动。

Answer 2

把它放在纯文本中是（我​​认为）严重的脆弱。事实上，人们可以提取罐子并阅读那些纯文本中的内容。

如果使用罐子是必须的，我会建议创建一个包含用户名，密码，URL等与final关键字类（只是一个简单的类）。尽管这种方法并不安全，但至少编译好的类不能被轻易读取。另一个优点（或者也许是缺点）是“硬编码”的连接属性不容易修改。即使你有源代码，你仍然需要重新编译它并重新烧录它。

Answer 3

我认为这样的事对于大多数开发商的惯例是一个配置文件保存在网站根目录之外。当然，如果这是一个桌面应用程序，而不是网络，这是不可能的。我之前在基于SWING的基于MySQL驱动的应用程序中完成的一些用户数量有限，而不是使用中间层进行身份验证，并使用MySQL的内置身份验证来呈现数据，以便所有安全性都可以在架构，然后复制每个用户的权限设置。一种骇人但可靠的方法。

Answer 4

我要阐明的东西经常说我的答案是：“任何人都可以创建一个他/她无法攻破的安全方案”。现在

，考虑其中的加密和模糊的提到在相同的更新是由的最新情况，这将是明智的注意，加密是不一样的混淆。从技术上讲，加密涉及使用密钥将某些明文转换为密文，明文只有知道原始密钥才可恢复。混淆根本没有接近加密的定义 - 它涉及从可执行源代码中删除信息，使可执行文件被认为“难以”进行反向工程。通常情况下，模糊处理涉及用较小的符号替换符号，有时，对源代码进行重新排序使得反向设计的源代码难以读取，同时保留原始的执行配置文件（混淆的源代码具有相同的代码和数据流路径作为原件）。

这里重要的是密码被编码到源代码中的事实。假设混淆源代码也将包含硬编码密码是合理的。这个假设是合理的，因为大多数混淆器从来没有试图改变constant pool within a class file - 突变常量池对于运行时行为会导致更改是很危险的。如果密码以字符串的形式硬编码到源代码中，则类文件（不论是否被模糊化）将在String constant pool中拥有密码，该密码将由JVM加载到内存中（没有解密或解码过程）之间）。

在这种情况下，最佳实践是让最终用户指定数据库用户标识和密码（如果他们正在管理应用程序设置），安全地存储这些用户提供的凭证（这取决于应用程序; Java EE应用程序应尝试让容器管理这些证书），并在从安全存储中检索这些证书时安全地管理这些证书。您可能想看看关于Insecure Storage的OWASP文章以获取更多的指示。

考虑到使用applet，建议不要在applet中包含数据库用户标识和密码。这需要完成各种原因 - 良好的应用程序允许更改数据库用户标识和密码，只需对应用程序进行配置更改即可。在源代码中对密码进行硬编码势必会增加管理开销;每当DBA选择更改密码时（这肯定会在一个理智的数据中心偶尔发生），您可能必须让最终用户清除其Java小程序缓存。此外，在部署对小应用程序的更改时，您可能还需要防止数据库帐户锁定。像其他推荐的建议一样，从中间层管理数据库连接将有很大的商业意义。