javase 数据库安全问题

Aanman 2017-03-16 04:02:11

java界面查询，比如一个登陆的javaSE程序，
生成jar或exe会不会被反编译看到连接数据库的信息，
这样就对数据库存在威胁性了，

如果有这样的情况，怎样防止呢？

...全文

205 6 打赏收藏转发到动态举报

写回复

用AI写文章

6 条回复

切换为时间正序

请发表友善的回复…

发表回复

ps45221 2017-03-17

打赏
举报

感觉你这种用法就很奇怪。。就算是C/S架构的程序，也有自己的服务端的，客户端怎么可能直接去连数据库。你是自己写的demo，还是实际应用遇到的？

杠__ 2017-03-17

打赏
举报

5楼正解，，

zs808 2017-03-17

打赏
举报

因为你如果直连数据库的话，连接信息是肯定要提供的，并且还必须是明文。因为你会提供源代码，所以任何在代码中对连接字符串的加密操作都将不可靠。如果要安全，就不能让源代码让用户可见，至少数据库连接这部分，不能让用户可见。众所周知，java的编译器做的工作大部分就是按照源代码进行“翻译”，转换成class文件，实际上，这个过程是可逆的，所以想通过编译的手段隐藏源代码是不可靠的了。那么，就没什么办法了么？？？非也，既然需要连接数据库，那么就必须保证客户端是有对数据库服务器的访问是连通的，既然必须保证客户端要连接服务器，为什么我们不能把与数据库操作相关的代码放到服务器上，然后客户端通过网络去服务器请求数据，服务器只提供结果，而不提供数据库的直接操作呢？这样就避免客户端与数据库直接操作，而服务端的代码对客户是不可见的，安全性就大大提高了，这就是C/S架构。 C/S架构的核心就是业务分离，将传统的单Client业务分为Client业务与Server业务。对安全性要求非常高的业务，核心业务逻辑，需要访问服务器资源的业务，以及保密性要求非常高的业务，作为Server业务实现，界面展示，直接跟用户打交道的业务，作为Client业务实现。然后Client业务与Server业务通过Http协议进行数据交换，这就是C/S架构的实现思路。另外，C/S架构还可以过渡到B/S架构，这样用户就无需专门的“客户端”来进行操作，只要通过浏览器访问你的服务地址，即可完成想要的操作，这种架构也是目前的主流架构。 ============ 回到楼主的问题，提高安全性的做法，推荐就是摒弃直连数据库，采用C/S分离业务逻辑，重新设计。这也是J2EE的价值之一。