Improving Web Application Security: Threats and - CGISecurity

228 Part III: Building Secure Web ApplicationsSettings in a separate XML configuration file define the policy for each level.Enterprise, machine, and user policy can be configured using the Microsoft .NETFramework configuration tool, but ASP.NET policy files must be edited manuallyusing an XML or text editor.The individual ASP.NET trust-level policy files say which permissions might begranted to applications configured at a particular trust level. The actual permissionsthat are granted to an ASP.NET application are determined by intersecting thepermission grants from all policy levels, including enterprise, machine, user, andASP.NET (application domain) level policy.Because policy is evaluated from enterprise level down to ASP.NET application level,permissions can only be taken away. You cannot add a permission at the ASP.NETlevel without a higher level first granting the permission. This approach ensures thatthe enterprise administrator always has the final say and that malicious code thatruns in an application domain cannot request and be granted more permissions thanan administrator configures.For more information about policy evaluation, see Chapter 8, “Code Access Securityin Practice.”Inside an ASP.NET Policy FileTo see which permissions are defined by a particular trust level, open the relevantpolicy file in Notepad or (preferably) an XML editor and locate the “ASP.NET”named permission set. This permission set lists the permissions that are configuredfor the application at the current trust level.Note You will also see the “FullTrust” and “Nothing” permission sets. These sets contain nopermission elements because “FullTrust” implies all permissions and “Nothing” contains nopermissions.The following fragment shows the major elements of an ASP.NET policy file:... list of security classes, permission types,and code group types ...