Isn't accessing private fields and properties

问题:

I just recently found out here that it is possible (at least in c#) to look up private fields and properties due to reflection.

I was surprised, although I knew that somehow constructs like the DataContractSerializer class need the possibility to access them.

The question now is, if anyone can access every field in my classes, this is kind of insecure, isn't it? I mean what if someone has a private bool _isLicensed field. It could be changed easily!

Later I found out here that the field accessors are not meant as a security mechanism.

So how do I make my Application safe, meaning how do I prevent anyone other than me from changing essential status values inside my classes?

回答1:

The question now is, if anyone can access every field in my classes, this is kind of insecure, isn't it?

Not everyone can. Only code with sufficient permissions - trusted code. Untrusted code is restricted quite a bit. On the other hand, if the person who wants to use reflection has your assembly, they can run trusted code on their own machine. That's not a new attack vector though, as if they've got your code they could also modify it to make the field public in the first place.

Basically, if code is running on their machine, you should expect them to be able to do pretty much anything with it. Don't rely on access modifiers to keep anything secret.

So how do I make my Application safe, meaning how do I prevent anyone other than me from changing essential status values inside my classes?

If the hostile user is running your code themselves, you pretty much can't. You can make it harder for them, but that's an arms race which is no fun.

So one option in some cases is not to let anyone else run your code - host it on the web in an environment you've locked down. That's not appropriate in all cases, of course.

If you have to let users run the code themselves, you need to weigh up the downsides of them tampering with the costs of making that tampering difficult. We can't really help you with that balancing act - we don't have any idea what your application is, or what the costs involved are (reputational, financial etc).

回答2:

private public and so on are a part of http://en.wikipedia.org/wiki/Encapsulation. the use is to make your API clear and to avoid mistakes.

there is no solid way to avoid people messing with your program. you may have noticed that all programs are cracked in a few days usually.

in .net it is VERY easy because of IL code been very readable http://ilspy.net/ and such allow you to take any DLL and just read it like C# code.

you can make it more annoying to read your code using obfuscator http://en.wikipedia.org/wiki/List_of_obfuscators_for_.NET

but applications like http://de4dot.com/ break this VERY easily.

SecureString is a nice trick: https://msdn.microsoft.com/en-us/library/system.security.securestring%28v=vs.110%29.aspx

writing your code in low level language like c++ might make cracking your code really annoying. but soon a skilled hacker will do whatever he wants with your program.

the only option that might be safe is providing your application as a cloud service where the user only sees the screen output and sends keyboard/mouse input.

回答3:

This was meant to be a comment for John Skeets answer but ran out of room..

Great answer by the way, but I also must add that code is not meant to be secure its meant to clearly defined.

Most developers know how to change classes and inject into classes. There are many utilities to not only decompile your code but to also allow injection into it.

I wouldn't spend to much effort trying to your make code more secure, I would try and expect the code to be changed. Many programming languages do not have such modifiers as private, public, internal, protected etc. They rely on the developers to understand the consequences of using this code on their own. These programming languages have been quite successful as the developers understand that modifying, calling or injecting into code the API does not specify has results that the developing company cant and will not support.

Therefore, expect your code to be modified and ensure your applications responds to invalid changes appropriately.

Sorry if this seems like a comment...

回答4:

To add to all the other answers, a simple way of looking at it is this: If the user really wants to break your code, let them. You don't have to support that usage.

Just don't use access modifiers for security. Everything else is user experience.