I recently joined a firm and when analyzing their environment I noticed that the SharePoint web.config had the trust level set to Full. I know this is an absolutely terrible practice and was hoping the stackoverflow community could help me outline the flaws in this decision.
Oh, it appears this decision was made to allow the developers to deploy dlls to the Bin folder without creating CAS policies. Sigh.
Just want to clarify and make matters worse, we are also deploying third party code to this web application.
Todd,
The book, "Programming Microsoft ASP.Net 3.5", by Dino Espisito provides some sound reasoning for not allowing Full Trust in ASP.Net applications.
Among other reasons, Dino states that web applications exposed to the internet are "one of the most hostile environments for computer security you can imagine." And:
a publicly exposed fully trusted
application is a potential platform
for hackers to launch attacks. The
less an application is trusted, the
more secure that application happens
to be.
I'm surprised the StackOverflow community did not outline the problem with Full Trust better. I was hoping for the same thing so I didn't have to go digging through my pile of books to find the answer, lazy me.
If they're ignoring the CAS policies, it might be a tough sell to get them to dial it back, since it makes their job a little harder (or, at least, a little less forgiving). Changing security practices is always tough - like when I had to convince my boss that using the SA accounts in the SQL connection string of our web applications was a bad idea - but hang in there.
Full Trust allows the application to escalate to control of any resource on the computer. While you'd have to have a security flaw in your application to allow these, and they'll probably claim that they've prevented any escalations through astute programming, remind them that in the case that something happens, wouldn't they rather the web application didn't have control of the whole computer? I mean, just in case?
EDIT: I was a little overzealous with my language here. Full Trust would allow the application to control whatever it wants, but only if the Application Pool process has sufficient rights to do it. So if you're running as a limited user with no rights on the server except what the applicaition needs, then I suppose there's essentially no risk to "Full Trust". The reality is that the app pool owner most likely has a number of rights you wouldn't want your app to have (and in some cases, many, many more), so it's much safer to limit app security and grant additional rights needs individually to the application. Thanks for the correction, Barry.
Flaws? Many. But the most damning thing is straight out of the CAS utility:
"...it allows full access to your computer's resources such as the file system or network access, potentially operating outside the control of the security system."
That means, code granted Full Trust can execute any other piece of code (managed or otherwise) on the system, can call across the network to any machine, can do anything in the file system (including changing permissions on restricted files - even OS files).
Most web programmers would say "that's not a problem, it's just my code," which is fine.... until a security flaw crops up in their code that allows an attacker to use it to do unsavoury things. Then previously-granted Full Trust becomes quite unfortunate.
I honestly have found sharepoint to be too restrictive.
Take a look at the following page to see what can and cannot be done based on trust levels
http://msdn.microsoft.com/en-us/library/ms916855.aspx
One problem I ran into immediately was I could not use the Caching Application Block. We were using this application block instead of the ASP.NET caching because we had used an MVP pattern and may open up a win forms application.
Another problem is no reflection, this caused the About page to fail because the version number is pulled from the metadata of the assembly.
I think the best solution is to not use Sharepoint as an application host. I would only use Sharepoint as an application host if the amount of coding was so small that it didn't affect the trust level and it would be less work then setting up a new application. If you are doing some type of coding which is starting to hit the walls of the trust level, move your application into a proper ASP.NET enviroment. But that is just me, and I am biased. Maybe you should try to aim for a Medium trust level compromise.
I use full trust on my development machines.. so I can deploy to the BIN when building new code.
I trust my own code and run it in the GAC on production because creating CAS policies is a pain.
The third party thing would have me worried.. however:
Most 3rd party solutions found on the web also deploy to the GAC (assuming for the same reasons). This gives them all rights regardless of trust level.
Feels like it has more to do with if you trust the 3rd parties or not.. and do you really trust your own developers?
What would a hacker do?
The scenario where a hacker drops an evil dll in your BIN folder I don't see as very realistic.. regardless if he can do that he can also probably change the trust level.
Related
I'm making an asp.net web application which will run locally on IIS
for a single user
I don't want this user to access my application files (in the www root ) or bring another programmer and steal my code
I just want the user to have the ability to access the website only and
stop any programmer from knowing my source code
I heard about an USB security system called "Dongle" but can it be used in a situation like this ?
any Ideas ?
thanks in advance
The website is just running code, but like anything, once the user has it they can do what they like to it, whether you like it or not. That's why there is a multi-million {currency} industry around securing applications.
You could use dongles but they're expensive and not trivial to implement. As #volleyball said, obfuscation would slow down most people from decompiling your app. without odfucation any licensing or dongles could just be patched out of your code.
Your most secure route would be to not give it to them. It's a web app, host it. This may not of course not meet your requirements.
Simon
I have never heard of a web application that uses a dongle. This is normally reserved for regular windows apps; and even then it's falling out of vogue. Generally speaking some of the more expensive software packages still use them.
However, the cost of duplicating a dongle is pretty low. Combined with the fact that getting around such security is relatively easy anyway and you have a situation in which you really shouldn't bother.
As Simon said, if it's a web app host it. Otherwise obfuscate it.
If neither of those are possible, then I'd recommend you change your licensing deal with your client to include the possibility of them going elsewhere. Perhaps for an additional charge you'll give them a non-exclusive site license permitting them to do whatever they want with the code short of selling it or giving it to another entity.
did you look at obfuscators. They do a good job at encrypting code. 99% of the time your code cannot be reverse engineered. But if someone sits on your stolen code they can reverse engineer.. In the sense that ordinary people may not obfuscate it. If the person is very intellingent, he will not reverse engineer he will write better code.
I'd like to know which are the security risks of running an asp net application with an administrator account.
I might end up doing this and I'd like to be aware of the known security wholes I would have.
I'm connecting to a sql server using sql authentication so excessive privileges to execute queries is out of the list.
I am having trouble coming up with a scenario where this would actually make sense -- you can always delegate specific permissions to a named user to get them the specific admin-style rights they need.
As for the question at hand, direct risk isn't any greater than any other web application inasmuch as a web app is a big honking hole through your firewall. The indirect risk is very, very scary. You are trying to turn the clock back to 2000 when IIS5 was setup to run as local system making every single case of "IIS can be made to run arbitrary commands" into "anyone can own your box over port 80."
If you do have to do this, I'd consider putting firewalls behind the server too. That way, when it does get rooted, you've got some defenses. I'd also use unique accounts, etc.
You should rarely need to run IIS under an administrative account. It's usually a sign of poorly written code. For example, I have seen it done when an app needs to shell out a batch job or executable, and needs to run those files under admin context to work (ie. very poorly coded applications).
You don't want to run any services under admin context. Not your IIS service, and especially not your database service. Any exploit triggered on your system will take on admin privileges, leading to a complete box compromise. Notice that in newer versions of Windows, both client and server, there are much fewer services running as either admin or system. This is due to Microsoft's own learnings that running apps under excessive privileges is a very bad idea.
The risk is completely endless; a single mistake in your code, or an as-yet-undiscovered IIS/ASP.NET security vulnerability and you would be giving potential crackers complete, unfettered access to the server.
Compared to running it under the default account(s), where access would be pretty restricted.
There's really no reason to need to do this anymore, especially with the newer Windows servers, ASP.NET versions and IIS.
The lack of reflection in Medium Trust hosting environments seems to cause a lot of problems for many popular web applications.
Why is ReflectionPermission disabled by default with Medium Trust?
What risk does reflection pose in a shared hosting environment?
For random reference, see MSDN: How to use Medium Trust in ASP.NET 2.0
Reflection allows malicious code to inspect all kinds of secrets: not so much intellectual property (though sure, that too), but data that should be private and secure, like connection strings, passwords, bank account data, etc..
Of course, many programs expose this data as a matter of course through even more-easily compromised vectors, but there's no reason to increase an application's attack surface.
Edited to bring some of the conversation up from the comments:
It's probably true that the real risk is unrestricted file system access, which is what turns reflection into a real danger. If a bad actor can get an assembly (or something that gets compiled into an assembly) into your virtual directory, you're in trouble if they have reflection permission. (Of course if this happens, there are other potential problems as well, but that shouldn't discount this particular vulnerability.)
In a shared hosting environment that's just harder to prevent, though it certainly isn't impossible. Perhaps it's worth cross-posting this question to ServerFault to see what the good folks there have to say.
I've never found anything 'bad' that a user will be able to do using reflection.
People get scared off because you're able to call methods that are marked as private or protected, but from what I've seen, none of them impose any real risk.
Most likely, it's at least in part a sales technique to get you to shell out for (semi-) dedicated hosting :)
I found the following MSDN article on this subject:
Security Considerations for Reflection
This article echo's Jeff's answer:
Reflection provides the ability to
obtain information about types and
members, and to access members.
Accessing nonpublic members could
create a security risk. Therefore,
code that accesses nonpublic members
requires ReflectionPermission with the
appropriate flags.
However, I don't believe this risk can be exploited between customer's hosting accounts. It appears this would only pose a personal risk. For example, using reflection I could explore my own assemblies in my hosting environment. Other customers, however, could not use reflection to explore my assemblies. They could only explore their assemblies.
This might pose a problem for a single web application that involves multiple development teams. One development team could use reflection to explore another development team's assemblies.
However, this is a rare scenario for a shared hosting environment. Most shared hosting web sites involve a very small team who have full access to all the code. In other words, there are no secrets. As long as the assembly is safe from other shared hosting customers, then it's not a problem.
Enabling reflection shouldn't pose any risk for most shared hosting web applications:
<IPermission class="ReflectionPermission" version="1" Flags="RestrictedMemberAccess"/>
Please correct me if I'm wrong.
What are the things that Medium Trust stops you from doing? For example, I've already learned that Medium Trust stops you from using System.IO.Path.GetTempPath(). What other things like that?
Here's how to learn about and resolve trust issues.
1) Search your Windows\Microsoft.NET\Framework[YOUR VERSION]\CONFIG folders for the files:
web.config (this is the root config file)
web_mediumtrust.config
web_hightrust.config
2) Change the web.config to say
<trust level="Medium" originUrl="" />
3) Try your ASP.NET app. Mine failed with a permission error.
4) Diff the web_mediumtrust.config and web_hightrust.config in a diff tool, like WinMerge.
5) Copy settings from the high to the medium one at a time and see how they affect your app. In my case, the error message referred to ConfigurationPermission, so it was easy to diagnose.
If you can pin down the precise lines in the web_mediumtrust.config file that are blocking you, then maybe you can share that with your hosting company and have a better chance of working things out.
More documentation here:
http://msdn.microsoft.com/en-us/library/aa302425.aspx
#Oli, my app IS hosted at GoDaddy and I had to do some workarounds in code when I started using Lucene.NET. I had to modify the Lucene.NET source code to not use GetTempPath and System.IO.FileInfo.
Who can be sure? That's why you should develop with a trust level of medium set in your web.config.
<trust level="Full|High|Medium|Low|Minimal" />
Most shared hosts don't use a true medium trust environment because it restricts some things that are just too vital. Others restrict some extra settings for their own anal reasons.
The best thing you can do is ask your host what settings they use for ASPNET. Ask for the specs of the trust level they're using. Find out the memory limits. Once you've got those details you should be able to replicate the scenario at a local level.
If they won't tell you, just set your app to run in medium trust but it (obviously) won't necessarily work if they're using a modified trust level.
Here is some information on setting trust levels in IIS.
In general the only issue I've run into is: If you're pushing assemblies, make sure you allow partially trusted requests (it's an Assembly meta-tag) otherwise you won't be able to use them.
Here's an extract of GoDaddy's Medium Trust information page:
Applications operating under a Medium
trust level have no registry access,
no access to the Windows event log,
and cannot use ReflectionPermission
(but can use Reflection). Such
applications can communicate only with
a defined range of network addresses
and file system access is limited to
the application's virtual directory
hierarchy.
Using a Medium trust level prevents
applications from accessing shared
system resources and eliminates the
potential for application
interference. Adding OleDbPermission
and OdbcPermission allows applications
to use those data providers to access
databases. WebPermission is modified
to allow outbound http and https
traffic.
That might not map exactly to what you'll have to work around with your host (unless you're with GoDaddy) but it's a typical example.
Make sure any third party libraries/frameworks (Castle comes to mind) are build (or can be built) in medium trust.
The system.runtime.serialization library is completely unavailable in medium trust.
I coded around this for json serialization/deserialization and found out the hard way. It took a week to get an associate to confirm that medium trust restrictions were to blame. I ended up switching hosting companies as a result.
In medium trust, at least at my host, P/INVOKE calls are unavailable, ie using [DLLImport] to call a COM component is not going to work.
-Edoode
I'm currently buying webhosting on a shared server with uses IIS6 and ASP.NET2.0 (They advertise 3.5 but investigation on my part has proven this to be false).
I did some legwork to make my 3.5-sensitive ASP.NET apps compile on my hosting then discovered another problem: My apps are failing at 'File.Open()' calls due to no FileIOPermissions.
I've called Technical Support and they've advised me this permission is only available if I configure IIS6 to use .NET 1.1 only. Am I out of line by thinking this is just not good enough?
This is something that should have been nutted out before starting to pay them, unless this disk access is a new requirement.
I can see it from their point of view. Every extra bit of power your apps have gives you more ability to shoot yourself (and more importantly, them) in the foot.
But I don't know why they'd allow it for an earlier .NET version, that seems bizarre.
I would make it clear that this is a deal-breaker. They might recapitulate, or you may have to move elsewhere. Either way, your problem will be solved.