类中私有字段值内的数据有多安全，以及如何使其更安全？
我有一个类，它在其私有字段中预加载一些值，这些字段用于进一步的计算。
我感兴趣的是从那时起，这些数据的安全性如何——黑客通过内存筛选来访问它的容易程度如何，等等。这里的完美场景是只有其名为 Class.CalculateSomething() 的公共方法才能访问这些字段并返回结果。
知道这可能是不可能的，有什么方法可以提高这些字段（主要是数字和字符串）的安全性吗？
I have a class that preloads some values inside its private fields and those fields are used in further calculations.
I'm interested from that point on, how safe is that data-- how easily can it be accessed by a hacker sifting through memory, etc. The perfect scenario here would be that only its public method called Class.CalculateSomething() would be able to access those fields and return the results.
Knowing that's probably impossible, is there any way to increase how safe those fields are, which are mostly numbers and strings?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您没有包含有关攻击者的最重要的事实：攻击者是谁？分析很大程度上取决于这个问题的答案。
如果攻击者是用户，那么你就完成了。如果攻击者拥有该机器，您将无能为力。 他们拥有机器。天啊，你甚至不知道他们是否运行Windows。他们本可以编写自己的操作系统和自己的 CLR。即使 CLR 中有安全系统，您也不能依赖它，因为攻击者可能会从自定义环境攻击您的代码。 代码不可能对确定的用户保守秘密。
在这种情况下，您所能做的就是 (1) 降低攻击者获取秘密的收益并 (2) 提高成本。一旦攻击的成本超过成功攻击的收益，理性的攻击者就会放弃。
但在这种情况下，最好两者都不做。 如果您不信任用户，请勿将机密放在用户计算机上。将机密保存在您拥有的计算机上。
如果攻击者编写恶意代码，然后诱骗用户运行该代码，那么您就有机会攻击它。如果用户授予恶意代码完全信任，那么恶意代码就被完全信任，我们的情况与以前相同；恶意代码是完全可信的，因此与用户一样强大；这就是“完全信任”的含义。
如果敌对代码是部分受信任的，那么为了允许它通过反射读取私有成员，必须授予它“跳过可见性检查”权限。
或者，可以授予其“受限跳过可见性检查”；被授予 RSV 的程序集可以查看任何被授予同等或更少权限的程序集的私有数据。
You do not include the most important fact about the attacker: who is the attacker? The analysis depends heavily on the answer to this question.
If the attacker is the user then you are done. There's nothing whatsoever you can do if the attacker owns the machine. They own the machine. You don't even know if they're running Windows or not for heaven's sake. They could have written their own operating system and their own CLR. Even if there was a security system in the CLR, you can't rely on it because the attacker might be attacking your code from a custom environment. It is impossible for code to keep secrets from a determined user.
In that case all you can do is (1) lower the benefit of the attacker deriving the secret and (2) raise the cost. Once the cost of the attack exceeds the benefit of a successful attack, a rational attacker will give up.
Better though in this case to do neither. Do not put secrets on a user machine if you don't trust the user. Keep the secrets on a machine that you own.
If the attacker is writing hostile code and then tricking the user into running the code, then you have a shot at it. If the user grants full trust to the hostile code then the hostile code is fully trusted and we're in the same situation as before; the hostile code is fully trusted and therefore is every bit as powerful as the user; that's what "full trust" means.
If the hostile code is partially trusted then in order for it to be allowed to read private members via Reflection, it's got to be granted Skip Visibility Checks permission.
Alternatively, it could be granted Restricted Skip Visibility Checks; an assembly which is granted RSV is allowed to look at the private data of any assembly that was granted equal or less rights.
没有办法阻止进程中运行的代码（在某种程度上，取决于处理器和操作系统，来自其他进程的代码）查看进程中的内存并读取它，或者更糟糕的是修改它。
此外，私有并不总是限制访问范围；反射可用于轻松检查和修改私有字段。
但是，您可以采取一些步骤来帮助保护您的数据。当涉及到字符串时，您可以使用
SecureString< /code> class它将加密内存中字符串的内容，并确保完成后清除内存。对于整数，我建议将它们转换为字符串，将它们存储在 SecureString 中，然后在需要时将它们拉出/解析它们。
请注意，在执行此操作时，您将看到性能影响（根据您的代码和使用情况，您必须看到多少影响），因为加密等将始终占用处理周期。
There is no way to stop code running in your process (and to some extent, depending on the processor and OS, code from other processes) from looking around at the memory in your process and reading it, or worse, modifying it.
Also, private doesn't always limit the scope of access; Reflection can be used to easily examine and modify private fields.
However, there are steps that you can take to help secure your data. When it comes to strings, you can use the
SecureStringclass which will encrypt the contents of the strings in memory and make sure to clear the memory when done.With integers, I'd recommend converting them to strings, storing them in SecureString, and then pulling them out/parsing them when needed.
Note, in doing this, you will see a performance impact (how much is something you will have to see based on your code and use), as the encryption, etc will always take up processing cycles.
通过反射可以轻松访问它们。无需黑客攻击。您是否正在尝试实现序列密钥检查器？这最好在本机代码 DLL 中完成，它更难破解，因为您需要更多知识...但是，它仍然不安全，正如您在每个破解软件中看到的那样...
They are easily accessible through reflection. No hacking needed. Are you trying to implement a serial key checker? This is best done in a native code DLL which is harder to crack, because you need more knowledge... But still, it isn't safe, as you can see with every cracked software out there...
我认为 private 没有按照您的预期使用。它用于执行面向对象的开发，而不是涉及防止数据盗窃的安全性。
如果您想防止其他人嗅探您的私人数据，加密是最好的方法。
I don't think private is used the way you are intending it. It's for performing Object Oriented development and not to do with security against data theft.
If you want to prevent others from sniffing at your private data, Encryption is the best way to go.
我认为您对于私有成员属性/变量的理解是错误的。它绝不保证类中的值的安全，并且仅在 OO 编程范围内相关。如果您需要保护应用程序中的信息，那么您需要考虑对数据进行加密，但请记住，解密数据的技术也将存在于您的代码中（可能具有可用的加密密钥）。
您需要强化操作系统和应用程序，限制对系统的访问始终是最好的方法。一旦破解者在较高级别上获得了对系统本身的访问权限，那么您就正在打一场失败的战斗。
I think you've got the wrong end of the stick with regard to private member properties/variables. It by no means secures the values within the classes and is only relevant within the scope of OO programming. If you need to secure information within your application then you'd need to consider encrypting the data but bear in mind that the technology for decrypting the data will also exist within your code (probably with encryption keys available).
You'd need to harden the OS as well as your app, restricting access to the system is always the best approach. Once the cracker gains access, at a high level, to the system itself then you are fighting a losing battle.
对于字符串安全性，您可以使用 SecureString 类。您也可以混淆您的代码，但这是一个只有当黑客足够懒惰时才会有帮助的解决方案。
For strings security you can use SecureString class. Also you can obfuscate your code but this is a solution which will help only if hackers are lazy enough.
这一点也不安全。筛选内存将显示您的数据。这不是
private的用途。It is not safe at all. Sifting through memory will show your data. That is not what
privateis for.一点也不安全。 Crack.net 将允许每个人检查进程，只要他们拥有机器上的权限。
Not safe at all. Crack.net will allow everyone to inspect processes, as long as they have permission on the machine.