views:

501

answers:

3

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

+1  A: 

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 :)

Thorarin
+3  A: 

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.

Jeff Sternal
I don't entirely understand how this works. For example, in a shared hosting environment how would I access another customer's assemblies? How would I use reflection to inspect the contents of private properties and methods?
Gabe
If you are (for example) running an web site project, rather than a web application project and you provide the user with a way to upload files to your site, they could upload an ASPX page that gets compiled when it's called - if that used reflection to read the state of your application, then it's possible that connection strings etc could be access.It's a slim possibility, but one none the less, hence the "could" in your link.Don't forget that some hosts don't always run a "vanilla" medium trust environment, but customise what features are and aren't available.
Zhaph - Ben Duguid
Ben beat me to it. I'll just add one more thing: in a shared hosting environment, you inherit (some of) the security vulnerabilities of the other applications running on your server, so your fellow customers don't even have to be malicious to pose a danger to you, just negligent.
Jeff Sternal
I know many web hosts don't run vanilla medium trust environments. Some hosts specifically enable reflection because of the problems it presents when disabled. I'm trying to assess if this is irresponsible, on their part, or a reasonable allowance.
Gabe
Full trust is right out, since that involves unrestricted FileIOPermission (which in turn enables all kinds of Reflection mischief) - but it might be the case that enabling Reflection (while otherwise running in MediumTrust) would be appropriate. It depends on how rigorous the hosting company's security policies are for their shared hosting servers. If different customers on the server are really protected from each other, it may be reasonable. However ...
Jeff Sternal
... there's always still a danger that another app on your shared server has a vulnerability that would allow an intruder to get file system access and therefore impersonate some assembly you're calling. Then, when you call that assembly, it can wreak its reflective mischief.
Jeff Sternal
@Zhaph - Ben Duguid In this scenario uploading a .aspx file is the vulnerability not reflection. If you have that level of access you could download all of the source code and reflection is then meaningless as an attack. **I have yet to see an attack i agree with in regards to reflection.**
Rook
@The Rook - *the sensitive data your application handles* is not available from its source code.
Jeff Sternal
+2  A: 

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.

Gabe
If access to the web application was compromised, then reflection could be used to explore the database connection strings and other sensitive information. It's a trade-off. How important is it that an application is protected from itself?
Gabe
@gabe to be honest this left me with more questions. Although +1 you confirmed that there are security concerns with a good reference. I respectfully disagree with you on the attack scenario, although i do not have a better one so i can't talk smack.
Rook