保护数据库免受 Java 客户端的攻击
我的概念使用一个中央 MySql 数据库，该数据库有许多 Java 客户端运行并使用该数据库（直接连接）。客户端将是公开可用的，因此安全性成为一个问题。
由于Java可以被反编译，我无法将该系统的安全部分放入客户端应用程序中。我需要一个初始用户名/密码来访问数据库，但除此之外，我无法真正保护客户端中的任何内容，因为黑客可以提取连接数据并编写自己的应用程序进行黑客攻击。
因此，这让我想到了参数化存储过程。这将使我能够通过将权限限制为仅 SELECT & 来稍微保护数据库。执行。而且，我正在考虑让每个 SP 都有用户名/密码参数，这样每次调用 SP 时都可以验证用户权限级别，以防止低级别用户破解/使用管理 SP。
这似乎提供了一定程度的安全性，并允许对数据库进行多级访问，但随后我遇到了 SQL 注入。
如果我使用参数化 SP，如何在 SP 将参数运行到数据库之前清除参数？在 PhP 中这很简单，但是对于本地运行的 Java 客户端，我没有服务器端应用程序来完成这项工作。我知道我可以在数据库和数据库之间放置某种服务器端应用程序。客户，但如果可能的话我想避免这种情况。
这有可能实现吗？ 那么它会“安全”吗？
这是解决这个问题的正确方法吗？或者是否有更好的方法来使用这种架构来实现此类安全性？
The concept I have uses a central MySql database which has many Java clients running and using this database (connecting directly). The clients would be publically available, so security becomes an issue.
As Java can be decompiled, I cannot put the security part of this system into the client application. I'll need to have an initial username/password to access the database, but beyond that, I can't really secure anything in the client, as a hacker could just extract the connection data and write his own app for hacking.
So, this led me to paramaterised stored procedures. This would allow me to secure the database a little by restricting permissions to just SELECT & EXECUTE. And, I was thinking about having each SP have username/password paramaters, so a users permission level could be verified with each call to the SP to prevent low level users from being able to hack/use admin SPs.
This appears to give a certain amount of security, and allows for multi-level access to the database, but then I got to SQL injection.
If I'm using paramaterised SPs, how can I clean the paramaters before the SP runs them onto the database? In PhP this is simple, but with a locally run Java client, I have no server side application to do this work. I know I could put some kind of server-side application inbetween the database & the client, but I want to avoid that if at all possible.
Is this possible to achieve?
Will it then be 'secure'?
Is this the right way to go about this, or is there a better way to implement security of this kind using this architecture?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为你需要去三层。您不能将数据库直接暴露给不受信任的客户端。您希望应用程序服务器位于两者之间。最终用户将登录到应用程序服务器（理想情况下，每个用户都使用单独的用户名/密码，该用户输入该用户名/密码，并且该用户名/密码不包含在应用程序中）。只有应用程序服务器连接到数据库，并且它只执行它认为合适的操作（例如：不直接运行从客户端获取的任何类型的 SQL，而是定义许多允许的方法/查询）。
如果您仍然想直接从客户端访问数据库，至少创建单独的数据库用户帐户（并且没有硬编码的密码）。但这（适当地管理所有权限）最终可能会给 DBA 带来太大的麻烦，并且配置错误可能会导致巨大的安全问题。
I think you need to go three-tier. You cannot expose your database directly to untrusted clients. You want an application server to sit in between. The end users would log in to the application server (ideally with a separate username/password for every single user, that that user enters, and that is not contained in the application). Only the application server connects to the database, and it only does what it deems fit (as in: not directly running any kind of SQL that it gets from clients, but defining a number of methods/queries that are allowed).
If you still want to directly go from client to database, at least create individual database user accounts (and no hard-coded passwords). But this (managing all the permissions appropriately) may end up to be too big a hassle for the DBA, and a configuration mistake can lead to huge security problems.