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