如何使用 java applet 与数据库安全通信
我已经用 PHP 和 MySQL 编写 Web 应用程序有一段时间了。我总是将数据库连接信息存储到配置变量中，并以这种方式连接到数据库。
客户希望他们的网站有一个 Java 小程序来与数据库进行通信。我对此非常犹豫，因为该小程序将公开，并且我不确定如何存储数据库连接信息。
我担心有人会反编译我的应用程序或找到某种方法来提取我的数据库连接信息并恶意使用它。
关于如何安全地执行此操作有什么建议吗？
I have been writing web applications for quite sometime in PHP with MySQL. I always stored my database connection information into a configuration variable and connected to the database that way.
A client wants a java applet for their website to communicate with their database. I'm very hesitant on this because the applet is going to be public and I am not sure how I would go about storing the database connection information.
I'm paranoid that someone would decompile my application or find some way to extract my database connection information and use it maliciously.
Any suggestions on how to do this securely?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只是澄清一下，您不太担心连接被“偷听”，您担心有人可能会破解您的小程序并提取数据库连接详细信息，对吧？
好吧，我可能不会让它直接连接，而是让它与以 JSON/XML 返回数据的 Web 应用程序对话。如果人们确实愿意，他们仍然可以从您的小程序中获取该内容，但他们仅限于网络应用程序的功能。
如果这不能让您满意，请确保小程序使用的数据库用户仅限于执行其需要的操作。如果只是拉取数据，则不要授予它插入权限。
如果您只进行写入，另一个选择是拥有一个公共数据库和一个私有数据库。小程序中的写入会进入公共数据库，并在验证后进行同步。这样做的问题是，除非您在公共数据库中保留所有数据的副本，否则您可能会丢失一些内置检查和关系 - 这可能不安全。
另一种选择是为每个用户提供自己的数据库用户。然后，如果未经授权的人要获取该小程序，他们仍然需要一个帐户才能进入。
我认为构建中间网络应用程序可能是您最好的选择，但我不知道完整的情况，所以我不最好的判断。
Just to clarify, you're not too worried about the connection being "overheard", you're worried that somebody might hack open your applet and pull out the database connection details, right?
Well I would probably not let it connect directly and instead have it talk to a web-app that returned the data in JSON/XML. People can still grab that from within your applet if they really want to but they're limited to what the web-app can.
If that doesn't float your boat, make sure that the database user the applet uses is limited to doing only what it needs to. If it's just pulling data, don't give it insert permission.
If you're only doing writes, another option is to have a public database and a private database. Writes from your applet go into the public DB and get synced over once verified. The problem with this is you might lose some built-in checks and relationships unless you keep a copy of all the data in the public DB - which may not be safe.
Another option could be to give each user their own database user. Then if somebody unauthorised were to get the applet, they'd still need an account to get in.
I think that building an intermediary web-app is probably your best bet but I don't know the full scenario, so I'm not best placed to judge.
我建议有一个与网站通信的小程序。它本身与数据库通信。
I would suggest to have an applet which communicate with the website. Which itself communicate with the database.
这是一个受信任的客户端问题，无需深入了解有关 JDBC 之上的身份验证扩展标准 JDBC 连接凭据，我建议您通过自己的数据库层包装所有请求。
我实际上使用 Ajax 实现了一个 JDBC 包装器，其中客户端从 JS 内向 Servlet 发出直接 SQL 语句，Servlet 将这些语句转换为数据库请求，我实现了更新和查询，整个实现不到 300 行 Java Servlet 代码和 60 行JS 代码。
该解决方案不包含任何身份验证，但可以轻松添加到 HTTP 层之上。无论如何，您有一个受信任的客户端问题，它并不能解决被黑的客户端可以在任何预定义或指定的用例之外访问整个数据库模式的问题，例如：
select * FROM reports而不是后端请求：
SELECT id, data, val, ... FROM reports WHERE userid = ...这只选择由经过身份验证的用户创建的记录。确保维护安全性的唯一方法是仅通过预定义的数据检索/修改方法访问数据库。否则，安全性和数据隔离必须由数据库本身强制执行，请阅读“昂贵的大O数据库”:)
我上面的400行JS/Java示例仅在测试系统中用于内部使用。
This is a trusted client problem, without looking to deep into JDBC regarding authentication extensions on top of the standard JDBC connections credentials, I suggest that you wrap all requests through your own DB layer.
I have actually implemented a JDBC wrapper using Ajax where the client issues direct SQL statements from within JS to a Servlet which translates those into DB requests, I implemented update and query and the whole implementation is less than 300 lines Java Servlet code and 60 lines of JS code.
The solution does not include any authentication but that is easily added on top of the HTTP layer. Anyway you have a trusted client problem, it does not solve the problem where a hacked client can access the whole database schema outside any predefined or specified use cases, e.g:
select * FROM recordsInstead of the backend request:
SELECT id, data, val, ... FROM records WHERE userid = ...Which only selects the records that was created by the authenticated user. The only way to ensure that security is maintained is to only access the DB through predefined data retrieval/modification methods. Otherwise the security and data isolation must be enforced by the Database itself, Read "expensive big O database" :)
My 400 line JS/Java example above is used in a test system for in house usage only.