I ran into a bit of a revelation today when I got a message from a customer who had been running our West Wind Web Store in development and ran into a number of issues when deployed on the server. As it turns out the ISP had turned down security to low and this is causing the application to fall down all because a lack of Reflection permissions on protected types.
I use a custom databinding scheme in my Web pages and this mechanism requires Reflection that usually binds object on a Page object to a control property. The problem is that these properties are generally defined as protected.
It turns out that Reflection has some limitations in any but the full trust permission set. Specifically Reflection is not allowed on any non-public types by default, which is configured through the ReflectionPermission security attribute.
The databinding usually ends up binding Business object Entity object properties to the various page controls and the problem is that the business object or other object like say a Configuration object tend to be protected objects on the page defined like:
protected busCustomer Customer = null;
Reflection requires non-public access to retrieve the property from the Page object without the Reflection permission.
The quick fix to the problem is to change the code use public references for the objects to be bound:
public busCustomer Customer = null;
and the problem went away. While that's not a terrible compromise and something I'll keep in mind for the future of the application and making it run under the widest possible security configurations, I wanted to at least figure out which permissions need to get set and how to do it.
To switch permission sets you change the security policy settings in the web.config file. You can do this in your local web.config file, if the machine.config isn't set to prevent overriding (as surely on an ISP site it would be).
So what I did is copy the webmediumtrust.config file in the .NET Framework config directory and copy it into my Web root. Again – if you're doing this at the machine or enterprise level you'd have to set this file up right in the .NET configuration directory.
In Web.config I can then change the policy file:
<configuration>
<system.web>
<!-- Use this security policy if you need to lower permissions
Please note the West Wind Web Store will run all the way down to Low
security but you need to add ReflectionPermission.
-->
<securityPolicy>
<trustLevel name="WebStoreMedium" policyFile="web_mediumtrustReflection.config"/>
</securityPolicy>
<trust level="WebStoreMedium" originUrl=""/>
</system.web>
</configuration>
The file copied requires a couple of changes. The first is to add the ReflectionPermission security class to the supported classes:
<SecurityClass Name="ReflectionPermission"
Description="System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"/>
Next is adding the actual permission to the permission set into the ASP.Net permission set:
<IPermission class="ReflectionPermission"
version="1"
Unrestricted="true" />
Save and run the app and the new policy should now work. This fix gets around this particular limitation.
From a security POV I'm not really sure how much of a compromise this is. Obviously it is considered a thread in that all but full trust (including HighTrust) don't allow it.
It's not a huge problem anyway – I'll move around the various binding members to public to make this work, but there are a number of other places I use Reflection in this way (optional though – like discovering control names for error messages) where there simply is no other choice I can think of…
Other Posts you might also like