Writing Secure .NET Code

Part IV

Special Topics

Chapter 13

Writing Secure .NET Code

As we venture into the brave new world of highly interconnected, Web-based services using HTTP as a transport and XML as a payload, the need for security is ever greater because the services can be exposed to a huge audience, an audience of potentially hostile people. As I mentioned in Chapter 1, The Need for Secure Systems, interconnected computers, such as those hooked up to the Internet, are prime candidates for attack. A stand-alone computer is far less likely to be subject to a security attack. Obviously, clients and servers using Web-based Microsoft .NET services are highly networked and therefore a heartbeat away from a security attack.

Managed code, provided by the .NET common language runtime, helps mitigate a number of common security vulnerabilities, such as buffer overruns, and some of the issues associated with fully trusted mobile code, such as ActiveX controls. Traditional security in Microsoft Windows takes only the principal s identity into consideration when performing security checks. In other words, if the user is trusted, the code runs with that person s identity and therefore is trusted and has the same privileges as the user. Technology based on restricted tokens in Windows 2000 and Windows XP helps mitigate some of these issues. Refer to Chapter 5, Running with Least Privilege, for more information regarding restricted tokens. However, security in .NET goes to the next level by providing code with different levels of trust based not only on the user s capabilities but also on system policy and evidence about the code. Evidence consists of properties of code, such as a digital signature or site of its origin, that security policy uses to grant permissions to the code.

	In my opinion, the best and most secure applications will be those that take advantage of the best of security in Windows and the best of security in .NET, because each brings a unique perspective to solving security problems. Neither technology is a panacea, and it s important that you understand which technology is the best to use when building applications. You can determine which technologies are the most appropriate based on the STRIDE threat model.

However, do not let that lull you into a false sense of security. Although the .NET architecture and managed code offer ways to reduce the chance of certain attacks from occurring, no cure-all exists. This chapter covers some of the security mistakes that can be avoided, as well as some best practices to follow when writing code using the .NET common language runtime, Web services, and XML. Let s begin by looking at what the common language runtime has to offer for defending against buffer overruns.

	The common language runtime offers defenses against certain types of security bugs, but that does not mean you can be a lazy programmer. The best security features won t help you if you don t follow core security principles.