What risk does Reflection pose? (Medium Trust)

Question

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

Answer 1

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.

Answer 2

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

Answer 3

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.