Best Practices for Security in the Visual Studio SDK
VSIP partners should acknowledge that they have a responsibility to understand security vulnerabilities so that they can create the best products possible.
A secure product helps protect the following:
Confidentiality, integrity, and availability of a customer's information.
Integrity and availability of the processing resources under the control of the system's owner or administrator.
A security vulnerability is a weakness in a product that makes it impossible to prevent an attacker's malicious activities, even when the product is used correctly. Here are some possible malicious activities:
Obtaining permissions on a computer that are higher than those of the user.
Taking over the operation of a user's computer.
Compromising data on a user's computer.
Never assume that your application will be run only in specific environments. Your application might be used in settings that you did not expect, especially when the application becomes popular. Assume instead that your code will run in hostile environments, and design, write, and test your code accordingly.
Products and systems designed and built with security as a prime feature are more robust than those written with security as an afterthought. Secure products are also more immune to media criticism, more attractive to users, and less expensive to and support and upgrade.
Many people tout certain APIs as dangerous. Although calls to some functions can produce unwanted security vulnerabilities if they are used incorrectly, banning their use does not necessarily produce secure code. Nevertheless, some software projects have obtained measurable gains in security by banning functions that are difficult to use safely, as one of many secure-development practices. For more information, see Appendix A of the Microsoft Press book, "Writing Secure Code" by Michael Howard and David LeBlanc.
The most important thing to understand in any discussion of dangerous APIs is that most security issues result from trusting input without adequately verifying it. Make sure that you trace data as it comes into your code and question the implications of operations on that data. You can write secure code by using most functions if the data inputs are well-formed and checked for trustworthiness.
User Account Control (UAC) in Windows Vista
Windows Vista adds a feature named User Account Control (UAC), which has security implications that VSPackage developers must understand. UAC reduces the attack exposure of the operating system and applications. For more information, see Developer Best Practices and Guidelines for Applications in a Least Privileged Environment.
Under UAC, an administrative user has the same rights as a standard user until a process that requires administrator rights is requested. The requested process prompts the administrator user for permission to continue. If granted, permission lasts only until the process is finished. For example, writing to a key in the HKEY_LOCAL_MACHINE registry hive or a directory in the Program Files folder requires administrator rights; under UAC, explicit permission from an administrator user is required to complete the writing operation.
To minimize the number of prompts, UAC elevation of rights affects a whole process and can occur only when the process starts. For VSPackages, the process is Visual Studio itself. Therefore, a VSPackage cannot run at a different level of rights than Visual Studio and other VSPackages.
Before Windows Vista introduced UAC, developers typically ran with local-administrator rights even when they were not needed. Therefore, Visual Studio and VSPackages could safely assume that they too had administrator rights. At this time, that assumption is still safe. Visual Studio 2005 must run in an elevated process on Windows Vista. Therefore, VSPackages would also have administrator rights. However, future versions of Visual Studio might not require elevation; therefore, make sure that your VSPackages do not unnecessarily require elevated rights.
Note that UAC also affects deployment. Windows Installer packages must be correctly authored to support UAC. Incorrect authoring usually presents itself as “access denied” errors, because the Windows Installer engine tries to use standard rights to perform a task that requires elevated rights..