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

Question

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

无论如何，我敢肯定这个开发人员如果在背后咬她，就不会知道有什么安全漏洞。而且我对Java/JAR文件还不太了解，不足以正确地告诉她应该做什么，只需要对infosec说她不应该做什么。

那么，在编写连接到远程MySQL数据库的分布式JAR文件时，典型的安全考虑是什么？是否有加密连接详细信息(用户名和/或密码)的标准方法？.jar文件不是只是美化了ZIP档案，难道没有人能解压缩文件并查看源代码中的连接细节吗？有没有加密jar文件内容的方法？

更新:我从开发人员那里得到了以下澄清。这听起来对吗？

jar文件中的所有类都被嵌入。在将所有类文件存档到jar文件中之前，我总是对它们进行加密。如果您打开任何经过编辑的jar，您只会看到加密的代码。因此，用户不可能通过解压缩类来查看源代码。类确实使用jdbc连接到db，搜索eangine需要连接到DB以运行sqls。这些sql位于jar文件中加密的clasee中。 当我问您如何加密DB密码时，我的意思是如下所示。我们将用java编写加密/解密代码并使用它。这些来自这个源代码的类将再次被加密，作为reoutine类加密过程的一部分。我们使用一个名为Retroguard的Java混淆工具对所有类进行加密。我们还嵌入一个键在html页面，以确保应用程序将只有当它已经下载的形式编辑的网站。如果用户将jar复制到他的本地机器并尝试运行它，它将失败。

Answer 1

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

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

这就是客户机/服务器应用程序消失的原因之一:很难在互联网上保护它们。

在我看来，你的应用程序听起来像是经典的客户端服务器。我有这个权利吗？

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

它还可以给您一个抵抗SQL注入攻击的机会。

如果加密JAR内容，则在加载时必须编写自定义类加载器来解密它们。不是为了心脏无力的人。

如果您的客户端是一个Swing应用程序，将所有的逻辑和数据库内容都内置到为每个组件注册的侦听器和事件处理程序中，那么您将需要认真地重写。您将转向更多面向服务的体系结构，其中所有的工作都是由服务器端的服务完成的。客户端只做它在经典MVC中应该做的事情:将事件传递到服务器端并显示结果。你的客户会轻得多。

这将是对您的开发团队和业务的最大冲击。

Answer 2

在开始我的回答时，我会说一些经常说的话：“任何人都可以创建一个他/她不能破坏的安全机制”。

现在，注意到在同一更新中提到加密和混淆的更新，最好注意加密与混淆并不相同。从技术上讲，加密涉及到使用密钥将一些明文转换为密文，而纯文本只能在了解原始密钥的情况下恢复。从定义上讲，混淆并不接近于加密--它涉及从可执行源代码中删除信息，这使得可执行文件被认为“很难”进行反向工程。通常，混淆涉及用较小的符号替换符号，有时对源代码进行重新排序，使反向工程源代码难以阅读，同时保留原始代码的执行概要(混淆的源代码具有与原始源代码相同的代码和数据流路径)。

重要的是密码被编码到源代码中。合理的假设是，混淆的源代码也将包含硬编码密码。这一假设是合理的，因为大多数混淆器从未尝试过突变类文件中的常量池 --变异常量池是危险的，因为它会导致运行时行为的变化。如果密码已作为字符串硬编码到源代码中，则类文件(混淆与否)将在字符串常量池中具有密码，该密码将由JVM加载到内存中(其间没有解密或解码进程)。

本例中的最佳实践是让最终用户指定数据库用户ID和密码(如果他们正在管理应用程序设置)，安全地存储这些用户提供的凭据(这取决于应用程序的性质；Java应用程序应该尝试让容器管理这些凭据)，并在从安全存储中检索这些凭据时安全地管理这些凭据。您可能需要查看关于不安全存储的OWASP文章，以获得更多的指针。

考虑到applet的使用，不建议在applet中使用数据库用户ID和密码。这需要出于各种原因--良好的应用程序允许只对应用程序进行配置更改就可以更改数据库用户ID和密码。在源代码中对密码进行硬编码必然会增加管理开销；每次DBA选择更改密码时，您可能都必须让最终用户清除他们的Java applet缓存(在正常的数据中心中，这种情况肯定会偶尔发生)。此外，在部署对applet的更改时，还可能需要防止数据库帐户锁定。与发布的其他建议一样，从中间层管理数据库连接将具有很大的商业意义。

Answer 3

我认为，对于大多数开发人员来说，这种情况的惯例是将配置文件存储在web目录根目录之外。当然，如果这是一个桌面应用程序而不是网页，那是不可能的。我以前在一个用户数量有限的基于SWING的MySQL驱动应用程序中所做的事情，不是使用中间层进行身份验证并将数据表示为服务，而是使用MySQL内置的身份验证，以便在模式中定义所有安全性，然后复制每个用户的权限设置。有点老套但很可靠。