Improving Web Application Security: Threats and - CGISecurity

196 Part III: Building Secure Web ApplicationsImplications of Using RequestOptional or RequestRefuseIf you use RequestOptional, the set of permissions that are specified withRequestOptional and RequestMinimum are intersected with the permission grantgiven to your assembly by policy. This means that all other permissions outside of theRequestOptional and RequestMinimum sets are removed from your assembly’spermission grant. Additionally, if you use RequestRefuse, the refused permissionsare also removed from your assembly’s permission grant.So if you use RequestOptional or RequestRefuse, your assembly becomes a partialtrust assembly, which has implications when you call other assemblies. Use thefollowing considerations to help you decide whether you should useSecurityAction.RequestOptional or SecurityAction.RequestRefuse:●●●Do not use them if you need to directly call a strong named assembly withoutAllowPartiallyTrustedCallersAttribute (APTCA) because this prevents you frombeing able to call it.Many strong named .NET Framework assemblies contain types that do notsupport partial trust callers and do not include APTCA. For more information,and a list of assemblies that support partial trust callers, see “Developing PartialTrust Web Applications,” in Chapter 9, “Using Code Access Security withASP.NET.”If you must call strong named assemblies without APTCA, let the administratorswho install your code know that your code must be granted full trust by codeaccess security policy to work properly.If you do not need to access any APTCA assemblies, then add permission requeststo refuse those permissions that you know your assembly does not need. Test yourcode early to make sure you really do not require those permissions.If downstream code needs the permission you have refused, a method betweenyou and the downstream code needs to assert the permission. Otherwise, aSecurityException will be generated when the stack walk reaches your code.Authorizing CodeCode access security allows you to authorize the code that calls your assembly. Thisreduces the risk of malicious code successfully calling your code. For example, youcan use identity permissions to restrict calling code based on identity evidence, suchas the public key component of its strong name. You can also use explicit code accesspermission demands to ensure that the code that calls your assembly has thenecessary permissions to access the resource or perform the privileged operation thatyour assembly exposes.