Securing Custom Control Designer Components
Many custom ASP.NET Web server controls have corresponding designer components that provide design-time rendering and editing features for the control. When the control is in design view, the designer component is processing property changes and rendering HTML for the design host (for example, Visual Studio 2005). At design time, the designer component of a custom control runs with the same level of trust as its design host. Designer components can potentially access databases, make calls to Web sites on a remote server, create and write files to the developer's computer, send e-mail, and execute code in other assemblies.
The information in this topic describes best practices that will help you improve the security of the control designer features.
While following coding and configuration best practices can help improve the security of your application, it is important that you continually keep your application server up to date with the latest security updates for Microsoft Windows and Internet Information Services (IIS), as well as any commercial custom-control packages that you have installed on your computer.
More detailed information about best practices for writing secure code and securing applications can be found in the book "Writing Secure Code" by Michael Howard and David LeBlanc, or through the guidance provided by Microsoft Patterns and Practices.
Issues for Custom Control Users
You should be aware that custom controls from unknown sources might contain designers that expose sensitive data from your computer to the Web, or run malicious code at design time. Also, you cannot use code access configuration to limit access for control designers since they must always run in the design host with full trust. For more information about trust levels, see ASP.NET Trust Levels and Policy Files.
Issues for Custom Control Developers
Using configuration attributes on classes and members to limit permissions to the minimum level required for the control's functionality doesn't really work for designer components since they must run in the design host with full trust.
If possible, always use example data structures to build data for previews of the runtime control rather than using potentially sensitive data from a database.
Issues for Design Host Developers
Developers of design hosts, such as Visual Studio 2005, should check HTML markup, text, and other data returned from the designer for security risks before displaying it. Also, limit the size of HTML markup strings and designer regions to manageable dimensions. For more information about HTML validation, see Validating User Input in ASP.NET Web Pages
See Also
Concepts
Introduction to Code Access Security
Reference
Validating User Input in ASP.NET Web Pages