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

听起来您的JAR包含一个直接连接到数据库的客户机。你不能说这是通过互联网还是VPN或LAN完成的。数据库是否从客户端远程部署?

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

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

通常在客户机和数据库之间引入一个中间层来检查安全性、验证和绑定输入,并将请求传递到适当的处理程序以实现。让用户提供中间层在将其传递到数据库之前必须验证的凭据。

它还可以让您有机会抵御SQL注入攻击。

如果加密JAR内容,则必须编写一个自定义类加载器,以便在加载时对其进行解密。不适合胆小的人。

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

首先,我要陈述一些常见的说法:“任何人都可以创建一个他/她不能破坏的安全方案”。

现在,注意到在同一个更新中提到加密和模糊处理的更新,明智的做法是注意加密和模糊处理不同。从技术上讲,加密涉及到使用密钥将一些明文转换成密文,只有知道原始密钥才能恢复明文。从定义上讲,模糊处理与加密没有什么相似之处——它涉及到从可执行源代码中删除信息,这使得可执行文件被认为“难以”进行逆向工程。通常,模糊处理涉及用较小的符号替换符号,有时,对源代码进行重新排序,使反向工程的源代码难以读取,同时保留原始代码的执行配置文件(模糊处理的源代码与原始代码具有相同的代码和数据流路径)。

这里重要的是,密码被编码到源代码中。可以合理地假设,经过模糊处理的源代码也将包含硬编码的密码。这一假设是合理的,因为大多数模糊处理程序从未试图改变 constant pool within a class file String constant pool ,它将由JVM加载到内存中(其间没有解密或解码过程)。

这种情况下的最佳实践是让最终用户指定数据库用户ID和密码(如果他们正在管理应用程序设置),安全地存储这些用户提供的凭据(这取决于应用程序的性质;JavaEE应用程序应该尝试让容器管理这些凭据),并在从安全存储检索这些凭据时安全地管理它们。您可能想看看关于 Insecure Storage

如果使用小程序,建议不要在小程序中包含数据库用户ID和密码。出于各种原因需要这样做—好的应用程序只需对应用程序进行配置更改,就可以更改数据库用户ID和密码。在源代码中硬编码密码必然会增加管理开销;每次DBA选择更改密码时,您可能都必须让最终用户清除javaapplet缓存(在一个正常的数据中心中,这种情况偶尔也会发生)。此外,在部署对applet的更改时,还可能需要防止数据库帐户锁定。与发布的其他建议一样,从中间层管理数据库连接将非常有商业意义。

把它放在纯文本中(我认为)是非常脆弱的。事实上,我们可以提取jar并读取用纯文本编写的内容。