Improving Web Application Security: Threats and - CGISecurity

182 Part III: Building Secure Web Applications●●Restrict which code can call your codeFor example, you may only want your assembly to be called by other codedeveloped by your organization. One way to do this is to use the public keycomponent of an assembly’s strong name to apply this kind of restriction. Thishelps prevent malicious code from calling your code.Identify codeTo successfully administer code access security policy and restrict what code cando, the code must be identifiable. Code access security uses evidence such as anassembly’s strong name or its URL, or its computed hash to identify code(assemblies.)How to Use This ChapterThis chapter takes up where Chapter 7, “Building Secure Assemblies,” left off. Itshows how you can use code access security to further improve the security of yourmanaged code. To get the most out of this chapter:● Read Chapter 6, “.NET Security Fundamentals” for an overview and comparisonof user (role)-based security versus code access security. Chapter 6 helps set thescene for the current chapter.● Read Chapter 7, “Building Secure Assemblies.” Read Chapter 7 before thischapter if you have not already done so.● Read Chapter 9, “Using Code Access Security with ASP.NET.” After you readthis chapter, read Chapter 9 if you are interested specifically in ASP.NET codeaccess security policy and ASP.NET trust levels.Code Access Security ExplainedTo use code access security effectively, you need to know the basics such as theterminology and how policy is evaluated. For further background information aboutcode access security, see the “Additional Resources” section at the end of this chapter.If you are already familiar with code access security, you may want to skip thissection and go to the “APTCA” (AllowPartiallyTrustedCallersAttribute) sectionlater in this chapter.Code access security consists of the following elements:● Code● Evidence● Permissions● Policy● Code groups