Improving Web Application Security: Threats and - CGISecurity

218 Part III: Building Secure Web ApplicationsDo Not Assert a Permission Before Calling a DelegateAsserting a permission before calling a delegate is dangerous to do because you haveno knowledge about the nature or trust level of the code that will be executed whenyou invoke the delegate. The code that passes you the delegate is on the call stackand can therefore be checked with an appropriate security demand. However, there isno way of knowing the trust level or permissions granted to the delegate code itself.For more guidelines about using delegates securely, see the “Delegates” section inChapter 7, “Building Secure Assemblies.”SerializationCode that supports serialization must be granted a SecurityPermission with itsFlag attribute set to SerializationFormatter. If you develop classes that supportserialization and your code supports partial trust callers, you should consider usingadditional permission demands to place restrictions on which code can serialize yourobject’s state.Restricting SerializationIf you create a class that implements the ISerializable interface, which allowsyour object to be serialized, you can add a permission demand to yourISerializable.GetObjectData implementation to authorize the code that isattempting to serialize your object. This is particularly important if your codesupports partial trust callers.For example, the following code fragment uses a StrongNameIdentityPermissiondemand to ensure that only code signed with a particular private key correspondingto the public key in the demand can serialize your object’s state.[StrongNameIdentityPermission(SecurityAction.Demand,PublicKey="00240000048...97e85d098615")]public override void GetObjectData(SerializationInfo info,StreamingContext context)For more guidelines about using serialization securely, see the “Serialization” sectionin Chapter 7, “Building Secure Assemblies.”