.Net SQLConnection 类是否有更安全的替代方案？
我很惊讶这个问题没有得到深入讨论：
这篇文章 告诉我们如何使用 Windbg 将正在运行的 .Net 进程字符串转储到内存中。
我花了很多时间研究 SecureString 类，它使用非托管固定内存块，并保持数据加密。很棒的东西。
当您使用它的值并将其分配给 SQLConnection.ConnectionString 属性（该属性是 System.String 类型）时，就会出现问题。这意味着什么？嗯...
- 它以纯文本形式存储，
- 垃圾收集将其四处移动，并在内存中留下副本
- 它可以使用 Windbg 内存转储读取
这完全否定了 SecureString 功能！
最重要的是，SQLConnection 类是不可继承的，我什至无法使用 SecureString 属性来创建自己的类；是的，闭源。耶。
新的 DAL 层正在进行中，但对于新的主要版本和如此多的用户来说，每个用户至少需要 2 年才能升级，其他人可能会出于某种原因无限期地保留旧版本。
由于连接的使用频率，从 SecureString 编组不会有帮助，因为不可变的旧副本会保留在内存中，直到 GC 出现。集成 Windows 安全性不是一种选择，因为某些客户端无法在域上运行，而其他客户端则通过网络漫游和连接。
如何保护内存中的连接字符串，使其无法使用 Windbg 查看？
I'm very surprised this issue hasn't been discussed in-depth:
This article tells us how to use windbg to dump a running .Net process strings in memory.
I spent much time researching the SecureString class, which uses unmanaged pinned memory blocks, and keeps the data encrypted too. Great stuff.
The problem comes in when you use its value, and assign it to the SQLConnection.ConnectionString property, which is of the System.String type. What does this mean? Well...
- It's stored in plain text
- Garbage Collection moves it around, leaving copies in memory
- It can be read with windbg memory dumps
That totally negates the SecureString functionality!
On top of that, the SQLConnection class is uninheritable, I can't even roll my own with a SecureString property instead; Yay for closed-source. Yay.
A new DAL layer is in progress, but for a new major version and for so many users it will be at least 2 years before every user is upgraded, others might stay on the old version indefinitely, for whatever reason.
Because of the frequency the connection is used, marshalling from a SecureString won't help, since the immutable old copies stick in memory until GC comes around. Integrated Windows security isn't an option, since some clients don't work on domains, and other roam and connect over the net.
How can I secure the connection string, in memory, so it can't be viewed with windbg?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您控制一台机器到可以读取另一个进程内存的程度，您还可以将对 SecureString 类的引用替换为对
string的引用。您将有权访问其他进程可以使用的任何私钥。对于拥有您的进程内存的黑客来说，没有任何防御措施。 :)
If you control a machine to the extent that you can read another process's memory, you can also replace the reference to the SecureString class with a reference to
string. You'll have access to any private keys that the other process can use.There is no defense against a hacker that owns your process memory. :)
这不是问题的真正答案，但仍然是：
尝试使用 Windows 身份验证而不是 sql 身份验证。即使您设法在程序内存中保护密码，用户也可以使用流量嗅探器看到它。
windows身份验证的另一个优点是sql server不需要存储用户的密码哈希。通过 SQL 身份验证，黑客可以从哈希中暴力破解密码或用另一个密码替换它。实际上，使用某些程序可以很容易地更换密码。
Not a real answer to the question but still:
Try to use windows authentication instead of sql authentication. Even if you manage to secure password in the program memory user can see it by using traffic sniffer.
Another advantage of windows authentication is that sql server does not need to store password hashes of users. With sql authentication determined hacker can bruteforce password from hash or substitute it with another one. Actually the password can be replaced very easily with use of some programs.
进程和 Sql Server 之间的通信理想地发生在主干上，如果主干受到损害，那么这是您最不需要担心的。
Communication between a process and a Sql Server ideally happens on a backbone and if that is compromised then this is the least of your worries.
由于它是一个客户端桌面应用程序，如果您想知道您的连接字符串凭据可能会暴露给某些黑客，这是一个设计缺陷...
如果您使用管理员凭据连接到 SQL Server ，这是你的问题。您应该创建一个有限制的用户并在您的应用程序中使用它。
如果您害怕公开数据库，您可以从应用程序访问网络服务。然后，该 Web 服务将访问数据库并返回结果。
Since it's a client-side desktop application, if you are wondering that your connection string credentials might be exposed to some hackers, this is a design flaw...
If you connect to your sql server with admin credentials, this is your problem. You should create a user with restrictions and use it in your app.
If you are affraid to expose your database, you could access a webservice from the app. This webservice would then access the database and return the results.