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 owner or administrator.
Security Vulnerability
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.
Important
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.
Dangerous APIs
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.
To install Visual Studio on Windows Vista, you must have administrator rights.
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 occurs only when the process starts. Elevation of rights for VSPackages occurs when Windows Vista starts. A VSPackage cannot run at a different level of rights than Visual Studio and other VSPackages.
Before Windows Vista introduced UAC, developers typically ran Visual Studio under administrator permissions even when they were not required. Therefore, they also ran only VSPackages that had administrator permissions. This is still true.
Visual Studio 2005 must run in an elevated process on Windows Vista. Therefore, VSPackages also run in an elevated process. However, future versions of Visual Studio might not require elevation. Make sure in the future 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. An incorrectly authored package typically causes "access denied" errors because the Windows Installer engine tries to use standard rights to perform a task that requires elevated rights.
See Also
Concepts
Best Practices for Security in VSPackages