Should I worry about the safety of my application if it runs in Full Trust level?
If yes, why? What damages could be done?
If the trust level should be a concern why it is the default level for asp.net applications instead of medium?
I know all the yes and no's between medium and full trust levels, but I can't see where this could be a serious risk to the application and server.
Considering this:
My ISP wants to (and will) change the trust level to Medium of an IIS asp.net mvc application running on a dedicated server. This simply will break my application, since it relies heavily on System.Reflection namespace and it uses 3rd party assemblies which don't have the AllowPartiallyTrustedCallers defined.
The application runs under a specific user that has read only access to the application directory and only execute permission on stored procedures on the Sql Server. The authentication is via SSPI, so no passwords on web.config.
The ISP claims that if they let my application run in full trust they can not guarantee the security of my server. I never heard about a single case when the full trust was the cause to a security break. It seems to me that they are not sure about what they are doing.
I can't see a security flaw here. The only securiy flaw I can see in general is the password stealing from the web.config, but this is not possible in my current setup…
Best Answer
Always grant only the privileges you really need.
Let's say you work in a company. Your work is limited to the room A and B and you might, sometimes, go to the room E. If you're given the access to the room C, D and F, it means that if something wrong happens in those rooms, you will be among the suspects. To limit the risks for the company and, at the same time, make it safer for you to work there, you will be given only the accesses you actually need or might need, but only those.
Source code is the same thing. When everything has full access and something wrong happens, you have no idea what happened. If, on the other hand, the protected file was altered while the file can be changed only by two people in the company and by a specific application, you know that either one of those people did something wrong, or their accounts were hacked, or the specific application was hacked. It becomes much easier to find the root cause of the issue and to be very reactive face to a security threat.
There are other reasons to use partial trust:
The code you write may differ from what you've meant. Imagine that you're creating a tool which will sync the files in some mission-critical directories every ten minutes from the machine A to the backup machine B. You finish the nth version of the app late in the evening and you mistakenly ask the tool to remove the source files from the machine A. You also make a few mistakes so that it doesn't copy the files from A to B. If you work in a partial trust where your application cannot remove any file from anywhere, never, it will just gracefully fail. Instead, in full trust, it will do the harm, then tell that it succeeded, letting you discover the consequences days later.
You may use third party components that you don't always trust or can't verify. Steven already discussed this point.
Partial trust applications can be executed in the context where the user, executing the application, has a partial trust too. It applies to the ordinary users, as well as IIS, daemons (Windows Services), etc. If you write your app for partial trust, you are aware of the pitfalls. If your application is intended to run in full trust and is started by a user who has a very limited set of permissions, what will happen?
Working in partial trust forces you to learn things you don't usually use in full trust context. For example, what about
IsolatedStorage? The advantages of isolated storage are not limited to the partial trust context (abstracting the way the information is stored; being sure that other non-malware applications will never access or overwrite the information you put there, etc.), but the feature is often ignored by people who work in full trust.Some contexts force you to use partial trust. Silverlight is an example.
If your full-trust code accepts plugins, it is a security threat. Unless you specifically determine the permissions granted to the plugins code which runs in the sandbox (which has some issues too; for example, it's not obvious for the sandboxed plugins to change the UI, as well as you may encounter some issues when using cache), the code of the plugins run with the same privileges as your application. Given that those plugins can be written by a third party and contain harmful code, the user will blame your app and not the plugin from doing the harm.