本文介绍了JAR 文件中通常如何实现安全的数据库连接?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我不是 Java 开发人员,但我的客户聘请了一名人员来更新他们网站上的一些 JAR 文件.在此之前,我们对现有代码进行了审计,发现了许多安全漏洞.我们用来使文件更安全的解决方案之一是创建一个新的数据库用户,该用户对数据库具有只读访问权限,并且仅适用于 JAR 文件需要操作的那些表.然后我发现他们将这些凭据与 JAR 文件一起存储在纯文本文件中,这只是一个远离公众的有根据的猜测.最后,今天他们要求更宽松的数据库权限,但我认为她不明白她真的不需要它们来编写正确编写的 JAR 文件.

I'm not a Java developer, but my client has hired one to update some JAR files on their site. Prior to doing so, we audited the existing code and found a number of security vulnerabilities. One of the solutions we employed to make the files more secure is to create a new database user with read-only access to the database, and only for those tables that the JAR files required to operate. I then found out that they are storing these credentials in plain text files alongside the JAR files, only an educated-guess away from the public at large. And finally today they are asking for much looser database privileges, but I don't think she understands that she really shouldn't need them for a properly written JAR file.

不管怎样,我很确定这个开发者如果咬到她的背面就不会知道安全漏洞.而且我对 Java/JAR 文件的了解还不够,无法就她应该做什么向她提供适当的建议,仅够了解信息安全来告诉她她不应该做什么

Anyway, I'm pretty sure this developer wouldn't know a security vulnerability if it bit her on the backside. And I don't know enough about Java/JAR files to properly advise her on what she should be doing, only enough about infosec to tell her what she shouldn't be doing.

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

So what are the typical security considerations when writing a distributed JAR file that connects to a remote MySQL database? Is there a standard way to encrypt the connection details (username and/or password)? IIRC, aren't .jar files just glorified ZIP archives, and couldn't anyone therefor unpack the file and view the connection details in the source code? Is there a way to encrypt the jar file content?

更新:我收到了开发人员的以下说明.这听起来对吗?

UPDATE: I received the following clarification from the developer. Does this sound right?

jar 文件中的所有类都是加密的.在将它们归档到 jar 文件之前,我总是加密所有的类文件.如果你打开任何 [redacted] jar,你只会看到加密的代码.所以用户没有机会通过反编译类来查看源代码.这些类确实使用 jdbc 连接到数据库,搜索引擎需要连接到数据库才能运行 sqls.这些 sql 位于 jar 文件中的加密 clasees 中.

当我问你加密数据库密码时,我的意思是你在下面说的.我们将用java编写一个加密/解密代码并使用它.来自此源代码的编译类将作为重新编写的类加密过程的一部分再次加密.我们使用名为 Retroguard 的 Java 混淆工具来加密所有类.我们还在 html 页面中嵌入了一个密钥,以确保该应用程序只有在从 [redacted] 网站下载后才能运行.如果用户将 jar 复制到他的本地机器并尝试运行它,它将失败.

when i asked you about the encrypting the DB password, I meant what you say below. we will write an encryption/decription code in java and use it. Thecompiled class from this source code will again get encrypted as part of the reoutine class encryption procedure. We use a Java obfuscation tool called Retroguard to encrypt all the classes. we also embed a key in the html page to make sure that the application will work only if it has been downloaded form [redacted] website. if the user copies the jar to his local machine and tries to run it, it will fail.

推荐答案

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

Yes, JARs are just ZIP files, so it's entirely possible to open one using WinZip and look at the contents. If you know what you're doing, you can find a plain text password inside.

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

It sounds like your JAR contains a client that connects directly to a database. You don't say whether this is done over the Internet or a VPN or a LAN. Is the database deployed remotely from the client?

这就是客户端/服务器应用程序消失的原因之一:很难通过 Internet 保护它们.

This is one reason why client/server apps went away: it's hard to secure them over the Internet.

对我来说,您的应用听起来像是经典的客户端-服务器.我有这个权利吗?

Your app sounds like classic client-server to me. Do I have that right?

通常在客户端和数据库之间引入一个中间层来检查安全性、验证和绑定输入,以及将请求传送到适当的处理程序以实现.让用户出示您的中间层必须验证的凭据,然后再将它们传递到数据库.

A middle tier is usually introduced between the client and the database to check security, validate and bind inputs, and shuttle requests to the appropriate handler for fulfillment. Have users present credentials that your middle tier has to validate before passing them along to the database.

它还可以为您提供对抗 SQL 注入攻击的机会.

It can also give you a fighting chance against SQL injection attacks.

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

If you encrypt the JAR contents you'll have to write a custom class loader to decrypt them when loading. Not for the faint of heart.

如果您的客户端是 Swing 应用程序,并且所有的逻辑和数据库内容都内置在为每个组件注册的侦听器和事件处理程序中,那么您将面临严重的重写.您将转向更多面向服务的架构,其中所有工作都由服务器端的服务完成.客户端只做它在经典 MVC 中应该做的事情:将事件传递到服务器端并显示结果.您的客户会轻松很多.

If your client is a Swing app, with all the logic and database stuff built into the listeners and event handlers registered for each component, you'll have a serious rewrite on your hands. You'll be moving to more of a service oriented architecture, where all the work is done by services on the server side. The client only does what it's supposed to in classic MVC: pass events along to the server side and display results. Your client will be a lot lighter.

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

That's going to be the biggest shock to your development team and the business.

这篇关于JAR 文件中通常如何实现安全的数据库连接?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-30 07:22
查看更多