Effective C # Principle 47: Choosing Secure Code

. NET runtime has been designed, some malicious code can not penetrate to the remote computer and execute. At present, some partial systems are lazy to download and execute code from remote machines. If you can publish your software over the Internet or Ethernet, or run it directly from the Web, you need to understand some of the limitations of CRLs in your assembly. If the CLR does not fully believe in an assembly, it restricts some behavior. The calling code is to have Access security authentication (CAS). On the other hand, the CLR enforces role-based security authentication so that the code can or cannot run under a special role account.

Security breaches are run-time conditions that the compiler cannot enforce. Luckily, they never appear on your development machine, and the code you compile is loaded from your own hardware, which means it has a higher level of trust. Discuss all the potential. NET security model can write a full number of books, but you can understand a small part of reasonable behavior, so that your assembly and. NET Safe mode is easier to interact with. These recommendations can only be referenced when you create a component library, or if you develop some components and assemblies that are published over the network.

Through this discussion, you should remember. NET is a managed environment. This environment is guaranteed to have a clear security environment. Available at installation time. NET configuration policy to manage security policies. Most. NET Framework Library is security-trusted for configuration policies at installation time. It identifies security issues, which means that the CLR can detect IL and ensure that it does not have any potentially risky behavior, such as direct access to raw memory. It does not require special security permissions to assert when accessing local resources. You should try to follow the same test, if your code does not need any security permissions, you should avoid using the CAS API to determine access rights, otherwise you will only reduce the performance of the program.

You will use the CAS API to access some protected resources that require additional privileges. Many common protected resources are unmanaged memory and file systems. Other protected resources include databases, network ports, the Windows registry, and the print subsystem. In each case, if the calling code does not have sufficient permissions, trying to access these resources throws an exception. Also, accessing these resources may cause the runtime to establish a polling on a security stack to ensure that all assemblies on the current stack have appropriate permissions. Let's look at memory and file systems to discuss some of the most practical issues in security systems and secret issues.

At any time, you can avoid unmanaged memory access by creating an appropriate set of security assemblies. A secure assembly, that is, one that does not use any pointers to access other unmanaged or managed heap memory. Whether you know it or not, all of the C # code you create is almost always safe. Unless you open the unsafe compiler switch/unsafe on the C # compiler, you are creating security code (even if the switch is turned on, it is not to say that it is compiled into unsafe code, but also to see how your code is written.) )。 /unsafe allows users to use a pointer to authentication that is not performed by the CLR.

There are few reasons to use unsafe code, especially in a regular task. Pointers to raw memory are faster than the security references to be detected. In some classic arrays, they can be up to 10 times times faster. But when you use unsafe structures, understand that any unsafe code will affect the entire assembly. When you create an unsafe block, you should consider using these algorithms independently in a single program letter (see Principle 32). This can limit the impact of unsafe code throughout the program. If it is independent, only the visitor who actually calls it will be affected. The rest, you can still use security in more stringent environments. You may also need to secure code to handle P/invoke or COM interfaces that require direct pointers. Same recommendation: independent of it. Unsafe code will only affect its own small assembly, there is no other.

The advice for access is simple: you should avoid access to unmanaged memory whenever possible.

The next security core is the file system. Program to store data. Code that is downloaded from the Internet, which is inaccessible in most parts of the file system, can be a major security breach. Yes, it's hard to create a program that you can use if you don't access the file system at all. This problem can be resolved by using isolated storage. Isolated storage can traverse an assembly-independent virtual directory, as well as the application domain, and the current user. Optionally, you can use a more general stand-alone storage virtual directory that is based on the assembly or the current user.

In fact, trusted assemblies can access their own special isolated storage areas, but not elsewhere in the file system. Separate storage directories are hidden in other assemblies and other users. You can use classes in System.IO.IsolatedStorage namespaces to access isolated storage. The IsolatedStorageFile class contains methods that can easily access the System.IO.File class. Actually, it's from System.IO. Derived from the FileStream class. The code for writing content to isolated storage is almost the same as writing to any file:

IsolatedStorageFile iso =
　IsolatedStorageFile.GetUserStoreForDomain( );
IsolatedStorageFileStream myStream = new
　 IsolatedStorageFileStream( "SavedStuff.txt",
　 FileMode.Create, iso );
StreamWriter wr = new StreamWriter( myStream );
// several wr.Write statements elided
wr.Close ();