Chapter 26. Testing a Secured Assembly | .NET Framework Security

for RuBoard

By Matthew Lyons

IN THIS CHAPTER

Determining What Is Being Protected
Determining How Resource Protection Is Implemented
Testing Any Applied Custom Permissions
Testing the Methods and Properties That Should Be Protected

In the .NET world, most applications do not need to explicitly write security measures. They get it "for free" from the .NET Framework class library. However, the default security provided by the .NET Framework class library isn't always sufficient. Perhaps an application will need to access a resource that wasn't exposed by the .NET Framework. Another possibility is that the .NET Framework class library did not expose resources in a way that an application needed. In these cases, a .NET developer will write a custom permission or use the default permissions provided by the .NET Framework in his or her own class library.

If you have simply used the .NET Framework class library in an assembly without any security stack operations or custom permissions, you can skip this chapter. However, if you have used any custom permissions or security operations (such as Assert , Demand , and LinkDemand ) in your assembly, this chapter is for you.

Testing a secured assembly has many concepts in common with testing any .NET Framework assembly. For example, correctness, performance, localization, usability, and reliability testing apply to a secured assembly just like they do for assemblies not applying any specific security measures. However, there are four unique steps for testing a secured assembly:

Define what is being protected as specifically as possible.
Understand how resources are being protected.
Test any custom permissions that are used to protect resources.
Test the protected code that directly accesses the resources.

for RuBoard