我开始考虑是否可以反汇编程序以检索它用于连接数据库的凭据，或者可能在运行时拦截程序并操作（SQL）查询（不是在谈论 SQL 注入）的问题.
也许这是一个荒谬的想法，但我需要知道我的客户收到的程序是否应该使用一个只能访问（和权限，即只读）特定表的帐户。
问问题
509 次
5 回答
2
这绝对不是一个荒谬的想法——有很多工具可以将程序反汇编成源代码。例如，在 .NET 世界中，您有Reflector和ILSpy，大多数语言都有类似的东西。
如果用户名或密码以纯文本形式出现在源代码中，则使用反汇编工具很容易获得它。如果它看起来是加密的，但加密算法和密钥是你源代码的一部分，那么它很容易获得。
为了解决这个问题，在 .NET 世界中，您可以在配置文件中存储加密密码。
或者，您可以将数据库配置为使用域身份验证，其中用户的域帐户被透明地用于访问，而不是硬编码的用户名/密码。
最后，您应始终尽可能使用最小权限原则- 仅允许用户权限执行所需操作的最小子集。
于 2012-09-03T14:59:02.173 回答
2
从理论上讲，您制作的每个程序都是要被反汇编的候选程序，因此您永远不应该将任何凭据直接写入它们。
根据您正在制作的程序类型，可以使用一些替代方法来编写凭据，例如在 Web 应用程序中，您应该使用 jndi 查找来搜索与您的应用程序分开创建的服务器连接，这样您就不会存储任何程序中的连接信息。
如果您正在编写桌面应用程序，您仍然可以使用 jndi 查找，但它会稍微复杂一些，在这种情况下，您可能想要创建一个服务器应用程序来处理来自服务器的身份验证和数据库连接，并且只会显示数据到客户端应用程序。
于 2012-09-03T15:01:27.243 回答
1
如果您为所有客户使用相同的帐户并且您要让它传播，这相当于根本不为该帐户设置密码（或将其公开），即使它已放入您的二进制文件中代码。那是因为事实上不可能控制一条超过 5 人的保留信息，即使这些信息是可靠的，他们使用的系统也不可靠。如果您真的想控制谁访问您的数据库（如您所愿），请将身份验证保留在受限制的位置，例如在服务器端，如上所述。
关于中间人攻击，如果您要通过不可靠的网络（例如，不是您的小型 LAN）进行通信，您应该假设这可能发生（嗅探 SQL 或任何其他类型的信息）并且您应该保护您的通信，例如使用加密连接（例如 SSL 或 TLS）。当然，除非您不关心发送的内容，或者您接受被拦截的中低风险。
于 2012-09-03T15:56:40.640 回答
1
从安全的角度来看，拆卸总是可能的。一个足够老练的攻击者可以只阅读机器代码并弄清楚它的作用，就好像它是正常的源代码一样。当然，这并不容易，但在“它需要像样的工具和一些聪明才智”的意义上是困难的，而不是“数学家认为需要比太阳预期寿命更长的时间”的意义上。
于 2012-09-04T02:27:07.527 回答
0
拆卸第三方产品通常违反许可协议，因此不建议单独使用。
也就是说，应用程序很少使用硬编码的数据库凭据，因为它们通常是特定于安装或部署的。许多应用程序将它们存储在 web.config 或 app.config 文件中。旧版应用程序可能会将它们存储在注册表中。
更好的解决方案可能是运行像WireShark这样的网络嗅探器并查看通过网络的数据包。如果是 SQL Server，默认使用 1433 端口。
于 2012-09-03T15:01:04.763 回答