Adopting Visual Studio Express Within Your Organization

  • Article

 

Rudolph Araujo
Foundstone Professional Services

October 2005

Applies to:
   Visual Studio 2005 Express Editions
   .NET Framework 2.0

Summary: This paper is designed to serve as a starting point to help organizations empower beginning, nonprofessional end-user development while preserving secure coding practices. (10 printed pages)

Contents

Background
Enabling Security
Other Recommendations
Conclusions
References

Background

Visual Studio 2005 is intended to reinforce the ability of developers to create Web applications, smart clients, Web services, and mobile applications in an easy, productive, and effective manner. In conjunction with the release of the .NET Framework 2.0, Microsoft is also attempting to make it easier for developers to write secure code by providing a lot of security by default and making it easy for development teams to make the right choices. One of the key additions to the current family of Visual Studio developer tools is the introduction of the Express Editions.

The Visual Studio 2005 Express Editions are designed for hobbyists, students, and novice developers looking to build rich and dynamic Web and Windows applications. While these editions lack the full breadth of features found in higher-end editions of Visual Studio, they are a first-class set of developer tools designed specifically with scenarios of interest to the nonprofessional developer in mind. Visual Studio Express might be used by people wanting to get on the path towards a career in software development, or possibly just for having fun, such as with some of the projects at the Coding4Fun developer center. But Express can also be used to create great applications that people can use to make them more productive in their jobs. This might mean creating a departmental Web site, or writing some utility services to help administer a server farm. The possibilities are limitless and present a wealth of opportunity for even nonprofessional developers to create compelling applications.

With the target audience described above being the focus, the Express editions include products for the C++, C#, Visual Basic, and J# languages, a product for Web developers, as well as a lightweight relational database system in Microsoft SQL Server 2005 Express Edition. Each Express product includes targeted documentation that will help the beginning programmer quickly learn the concepts required to build more advanced applications. The user interfaces are significantly streamlined to ensure that extraneous features do not interfere with the learning process. The fundamental idea is that the Express products will guide the novice carefully so they are successful and gain confidence early in their programming career while still allowing them to enjoy themselves and be productive.

While novice developers have never had it better, this might raise a few concerns for an organization. Empowering the individual to leverage IT assets isn't always a welcome experience. When applications "come up from the floorboards" within an organization, they can sometimes bring with them unwelcome security issues that may pose a threat to corporate data or mission-critical resources. For instance, novice developers may not entirely understand key secure programming principles such as access control and the need for structured exception handling. Thus, they may inadvertently end up exposing key organizational assets such as confidential or proprietary data or critical system functions to unauthorized users. They might also provide a vector that can be used by an attacker to attack other more significant and core applications by revealing (for instance) database schemas or other configuration information. In order to address these legitimate concerns this paper is designed to serve as a starting point to help organizations empower end-user development while preserving secure coding practices. It not only highlights mechanisms already available in the Express Editions that were designed precisely to help prevent some of the scenarios described above from being realized but also provides accurate, relevant, and timely guidance about how organizational administrators can enforce policies that will help prevent critical application vulnerabilities from manifesting themselves.

Enabling Security

As mentioned above, security was a key design goal of this release. This is both in making the Visual Studio product suite itself secure by default, but also in providing a secure development environment and in allowing developers the ease of building their applications to be secure by default as well. With these goals in mind, a number of key features help enable this vision:

  • Built-in Web server: For developers building Web applications one of the biggest constraints is the need to have Internet Information Services installed on the development machine. From an administration standpoint this often proves to be a tremendous hassle since IT staff has to now ensure that the Web server running on each developer's machine is not vulnerable to Web server attacks, is not accessible from outside the local network. Further, this would often require the developers to have administrative privileges on the Web server as well so that they could go about being productive during development, configure settings, and debug their applications.

    To cope with these and other problems, Visual Web Developer 2005 Express edition comes equipped with a built-in Web server that runs within the development environment itself. At first, this configuration might sound a little troublesome and less secure then the prior environment. However, a number of security features provide for a secure deployment by minimizing the attack surface and thus decreasing risk. These features are enumerated below.

    • The built-in Web server is configured so that it can only accept requests from the local system. Thus it cannot be accessed from other hosts on the network and is thus protected from malicious attackers exploiting Web server vulnerabilities over the wire.

    • The Web server built in to the Express editions does not use the standard port 80 traditionally used by HTTP servers. Instead the port number is randomly selected and assigned each time the Visual Studio environment is launched. This again ensures that malicious attackers or software attempting to find and exploit the Web server will have little success.

      As a consequence of the built-in Web server, end developers will no longer have the need to have the full IIS Web server installed on their machine or be required to modify settings of such a server. This provides developers with the ability to write code without running as an administrative user on their development machine. While this in itself is an excellent security benefit, a consequential benefit is that it also makes developers more conscious of what operations their application can and cannot perform without administrative privileges. Thus, developers are almost forced into building applications that do not need administrative privileges to run.

      The use of a built-in Web server does raise a few deployment questions, however, the biggest of which is how and when to move from the built-in Web server to a production system running the full IIS Web server. The answer to this often depends on organizational policy. If the application is approved for deployment, IT administrators or the developer can publish the application to the production Web server, which is hardened and configured securely. The ability to do this is in fact provided within the Visual Studio environment itself. Thus, the administrators have to concern themselves only with the maintenance of the production systems and do not have the additional administrative burden of the developer machines. Moreover, in a later section of this paper we also describe how administrators can use code access security policies to control both this process and the execution of the application itself.

  • IntelliSense-in-zone and Debug-in-zone: The IntelliSense-in-zone feature can be used in conjunction with code access security policies to help developers make right choices about the APIs they use in their application. When running in Visual Basic, the IntelliSense feature provides visual feedback to let developers know about any APIs that are not available within the current execution zone and hence those that would cause the application to violate the security policy. For instance, if executing from the Local Intranet zone, an application can only read the "username" environment variable by default. The IntelliSense-in-zone feature will therefore visually flag any attempts to violate this policy, such as attempting to access other environment variables.

    The Debug-in-zone feature is also fairly similar and meant to aid in achieving the same goal. In this case developers can debug code as if it were executing within a specific zone or with a defined code access security policy. Thus developers can detect violations early and learn about the execution sandboxes that each of the zones provides.

    By providing the programmer with these tools at development time, it is possible to make the right choices up-front and avoid costly re-coding and deployment if these problems were only discovered in production. This also makes it easy for developers to write code that runs in specific sandboxes that the administrators can then use to control the access rights associated with the applications created by the nonprofessional developers using the Express editions.

  • ClickOnce: ClickOnce is a new application deployment technology that attempts to make the process of deploying a Windows Forms based application as simple as deploying an ASP.NET Web application. From the end-user's perspective, with ClickOnce running a Windows Forms application is as simple as clicking a link on a Web page. Similarly for administrators, deploying or updating such an application is as easy as updating the appropriate files on the server without the need to modify every individual client. Thus ClickOnce applications are fundamentally low-impact and are completely self-contained and installed per-user. As a consequence, importantly, they do not require administrative access on the local system. Also, there is no risk of a ClickOnce application breaking other applications since these run isolated from other applications on the client system. However, it should be noted that if the application does need to perform complex or privileged operations at install time, such as installing device drivers, organizations are better off leveraging MSI. While this latter process is much more involved and complex then ClickOnce, it is also something that administrators are likely to want to be more involvement in.

    ClickOnce applications can be deployed via Web servers, file servers, or CDs. Such an application can choose to be installed on the local machine, which implies that entries are created in the Start menu and Add/Remove programs; or the application can simply be run from its current location and cached. ClickOnce applications are also provided with several ways to automatically check for application updates. Alternatively, applications can use the ClickOnce APIs under the System.Deployment namespace to have more granular control of when and how updates take place.

    The Express products have rich native support for the ClickOnce deployment technology. The developer can choose to publish the application from Visual Studio itself and the development environment will automatically create the necessary XML manifest that enables the ClickOnce process. Obviously, administrators will want to control keenly who can publish to which servers and this paper makes some specific recommendations (about using authorization, for instance) in the Other Recommendations section of this document.

    ClickOnce applications run within a secure sandbox provided by code access security policies. This means that the IntelliSense-in-zone and Debug-in-zone tools described above can provide tremendous help during the development process to a developer attempting to create ClickOnce applications. The use of tools like PermCalc.exe can also aid the developer in identifying exactly what permissions are needed by the application to successfully execute and in comparing those with the permissions granted to the zone the application will be executing from. For applications that do need a higher set of permissions to execute, the ClickOnce model supports both the ability for users to make the decision as well as an administratively defined pre-deployment security policy-based approach.

  • Partial Trust Development: Partial trust applications run with reduced privileges that prevent them from writing to arbitrary parts of the file system, connecting to hosts on the Internet other than the origin, and performing privileged operations such as calls to unmanaged code. These restrictions are intended to both protect the underlying host from being compromised due to vulnerabilities in the application in question, as well as to protect other applications running on the same server. This is extremely common in shared hosting scenarios with an out-sourced provider as well as when an organization runs multiple Web applications on the same machine.

    In prior versions of the .NET Framework and Visual Studio, creating partially trusted applications was far from easy. Developer tools were not available and perhaps even more significantly the partial trust sandbox was so severely restricted that creating any meaningful application that could successfully run in partial trust was an almost impossible task. With one of the main goals of this release being security, writing partially trusted code with the 2.0 version of the Framework and Visual Studio 2005 is far simpler and indeed plausible. While some of the changes that help—such as PermCalc.exe, Debug-in-zone, and IntelliSense-in-zone as described above—the following is a discussion of some of the key changes that have made the goal of creating a real-world partially trusted application at least in part a reality:

    • Partially trusted developers finally have the ability to connect to a database. With the SqlPermission and SqlNotificationPermission being granted in the default medium trust grant set, developers can, for instance, use the classes of the System.Data.SqlClient namespace to connect to a Microsoft SQL database. Consequently, developers can now build rich 2 and 3 tier applications that leverage a backend database for persistent storage while still executing in partial trust. The only real reason for running in full trust post this release is if the Web application must leverage legacy code through P/Invokes or COM Interop. If using a non-Microsoft SQL Server database, developers have the option of using the OleDb classes available in the Framework. While the OleDbPermission is not part of the default medium or high trust grant for ASP.NET, developers do have the option of adding this specific permission to a custom code access security policy and then using that. This is possible only because the OleDb provider in the .NET Framework 2.0 no longer demands full trust and is therefore accessible.
    • Similarly to the SqlClient namespace, the ability to send e-mails is another ability that a number of applications would need. With the .NET Framework 2.0 comes a new permission, SmtpPermission, which is included in the default partial trust grants for ASP.NET 2.0 Web applications. This permission in turn is demanded by the SmtpClient class.
    • The often hated SecurityException has been significantly enhanced in the .NET Framework 2.0. Again the key goal here was to make it easier for developers to decipher what was causing the exception as well as which permission being demanded they were missing. Thus developers can easily make a decision about whether they will attempt to avoid the operation or add the missing permission to the grant set. This new exception object has also been tightly integrated into the Express editions and indeed all of the Visual Studio 2005 products. When such an exception is raised during debugging the IDE will observe all the values of the properties of the object and then display context-sensitive help and rich feedback to the developer to enable getting to the bottom of the issue.
    • The .NET Framework 2.0 also provides a simple sandboxing API that can be used to execute untrusted code in the form of a plug-in or third-party components within a trusted hosting application. Thus, the host may chose which permissions it would like to grant the untrusted code. Specifically, the method that enables this mechanism is a new overload of the AppDomain.CreateDomain method. Similarly, the introduction of the AppDomainManager class is also intended to allow the hosting application more fine-grained control over the set of operations the hosted code is allowed to perform and in fact the general execution of this code. This mechanism can very easily be used to restrict and constrain applications created by novice and nonprofessional developers.
    • In prior versions of the .NET Framework, an attribute termed as AllowPartiallyTrustedCallersAttribute or APTCA could be used to allow partially trusted code to invoke strongly named code quite commonly running from within the Global Assembly Cache (GAC). Without this attribute, partially trusted code would fail the implicit demand for full trust that is introduced by strong naming an assembly. While this mechanism was meant to help partial trust developers to invoke system functions and common libraries, it did come with the risk of a luring attack. An assembly marked as APTCA is now callable by any partially trusted code and thus may be maliciously invoked by a Web application other than the one originally intended. Often such strong named assemblies would assert specific permissions before performing privileged operations to stop the stack walk within the full trust signed assembly and prevent it from propagating back to the partially trusted code where it would fail. A code access security assert can almost be considered an elevation or privilege and hence must be handled very carefully. To help make managing and dealing with APTCA assemblies a little easier, the .NET Framework 2.0 introduces the notion of security transparency. Marking an assembly as security transparent tells the runtime that this assembly is never intended to perform an assert and thus any call to assert a permission will result in an exception being raised. Similarly, an application may be marked as security critical, which implies that the assembly is security transparent in general but may have a few functions or properties that may need to assert and therefore would be marked with a specific security critical attribute. Thus any attempt to invoke a permission assert will result in an exception except in those code blocks decorated with the security critical attribute. Along with making it easier for the developer to write better and more secure code, this feature also makes it easier for code auditors to review code marked as APTCA in an efficient but effective manner. Automation support for this feature has also been provided via the FxCop analysis tool.
    • The .NET Framework 2.0 also introduces a HostProtectionAttribute, which an application can use to inform the runtime about any functionality within that may potentially damage the underlying host, the application itself, or threads either within or outside the application. This is yet another mechanism for developers to leverage in their aim of writing secure by default software that fails securely and deals with potential errors in such a way as to prevent system compromise.

It is important to mention that the above list represents only a small subset of the features available within the Express editions and the .NET Framework that can be used to enable security and prevent nonprofessional developers from creating applications that could result in critical organizational assets being exposed to malicious users. The rest of this document now focuses on what else administrative staff can do to prevent vulnerabilities while still allowing novice developers to learn and be productive.

Other Recommendations

Code access security policies have been available ever since the earliest versions of the .NET Framework. These policies determine what an application can and cannot do by defining the set of permissions granted and thus defining the access allowed. These policies exist primarily at four levels: enterprise, machine, user, and appdomain. The final policy enforced is then determined as an intersection of the policies at each of these levels. Thus the highest permissions an application can have is one of the individual levels. Administrators can thus use the enterprise level policies to enforce that code created using the Express edition is executed using a very restrictive permission set.

With the .NET Framework 2.0 it is also possible now to precompile and strongly name compiled ASP.NET 2.0 assemblies. Source files such as .aspx files no longer need to be deployed on the Web server. As part of this precompilation process it is also possible to cryptographically protect the assembly by using a strong name. By using such strong names and policies as described above it is again possible to restrict applications at an enterprise policy level. For instance, one possibility is to use group policy (or software restriction policies as described in a referenced article below) to only allow escalated permissions to the applications that are "signed" by the IT department or come from one of the approved servers. Other applications created by users within your organization possibly by using developer tools like the Express editions would not be signed and hence can't receive the elevated permission set by default. This mechanism uses a cryptographic approach for distinguishing between full trusted desktop applications and untrusted potentially malicious applications and code written by novice developers. The process for doing this is fairly simple. Administrators would create a custom code group based on a specific public key or strong name. They could then assign permissions based on an existing or custom permission set to this code group using the .NET Configuration tools.

If needed, organizations can also set up a process for novice developers to get their applications signed. This process must include a thorough threat modeling effort and code review before any applications are approved. This is perhaps also a good opportunity to teach novice developers about the nuances of secure software engineering practices as suggested later in this paper.

IT administrators should also use configuration management mechanisms to protect the underlying host and other applications from potential malicious activity within the application in question. This can be done by using mechanisms such as URL authorization to prevent the application from accessing parts of the file system without having very specific roles and permissions. Similarly, cross-application redirects can be used to prevent applications from interacting with each other in a malicious manner. This can be done with tokens such as the one used for forms authentication. Options to disable cross-application redirects are now available as part of the Framework itself and can be configured through the config file. For instance, for an ASP.NET 2.0 Web application this can be done using the Web.config file. Similarly, all critical resources within the organization must be tightly access controlled. For instance, there is no reason why the database containing social security numbers and credit card information for your customers be exposed to a novice developer just learning to program. By controlling access to such resources, administrators can ensure that both inadvertent damage and malicious activity can be easily avoided. Other mechanisms that may be used include having appropriate change management processes in place, strong authentication, and maintaining an audit trail of all events that have occurred to allow for non-repudiation.

Finally, a lot of security is achieved by covering three major facets: people, process, and technology. In most of the discussion above we have focused primarily on the technology piece. It is also important to have the right policies in place and the processes to enforce those policies as well. For instance, novice developers must be educated in techniques such as threat modeling and code review. There is no better time to teach people about writing secure code then when they are learning to write code in the first place. Students and novice developers must be taught about the basics of software security, including fundamental concepts such as cryptography, authentication, and authorization. Policies such as coding standards, security deployment standards, information security policies, data classification guidelines, and guidance on performing threat modeling and code reviews must be developed and enforced. Similarly, administration teams can work with developers to go through an internal certification program for their applications, which includes performing a threat model on the application followed by a security code review.

By investing in the people and processes, organizations can achieve greater success in securing their environments than by only being reliant on the best technology.

Conclusions

Novice developers, students, and people new to programming on the Windows platform and .NET Framework have never had a relatively cheap but rich environment through which they can create applications either to learn or potentially even to simplify their and others' jobs. The Visual Studio 2005 Express Editions aim precisely to solve this problem. However, they also raise a natural concern for organizations that worry about the security impact of nonprofessional developers creating applications, including those that run over the network. Badly written applications can lead to the compromise of the application, the underlying host as well as other applications running on the same host, and even to the disclosure of sensitive data such as customers' personally identifiable information, intellectual property, and trade secrets. This paper is meant to assuage some of the fears by pointing out many of the key features that enable secure application development in the .NET Framework 2.0 as well as in Visual Studio 2005. The good technology in these products can go a long way in preventing vulnerabilities. Organizations must also focus on the people themselves as well as process. But by following these guidelines, an organization can allow even its nonprofessional developer constituency to build great applications that may ultimately help them perform more effectively.

References

 

About the author

Rudolph Araujo is a Senior Software Security Consultant and trainer at Foundstone. At Foundstone, Rudolph is responsible for creating and delivering the threat modeling and security code review service lines. Rudolph is also responsible for content creation and training delivery for Foundstone's Building Secure Software and Writing Secure Code—ASP.NET class.

Rudolph has strong computer science fundamentals and many years of software development experience on both the UNIX and Windows environments. Prior to joining Foundstone, Rudolph led the checks development team for BindView bv-Control for Internet Security, a vulnerability assessment product. He has also worked as a software developer at Morgan Stanley. Most recently, Rudolph has worked as a researcher at Carnegie Mellon University's CYLAB investigating virus and worm threats, especially over peer-to-peer networks. His research interests also span the domain of Web service security and reliability.

Rudolph holds a Masters Degree from Carnegie Mellon University with a focus on information security, and a Bachelors Degree in Computer Engineering from Goa University in India. He is an experienced C/C++ and C#/.NET Framework developer and the author of Foundstone's .NET Security Toolkit, SSLDigger, and Hacme Bank tools. Rudolph is also a presenter in MSDN's Webcast series. Rudolph has been honored with the Microsoft Visual Developer Security MVP Award in recognition of his thought leadership and contributions to the application security and developer communities. Rudolph is also a contributor to multiple online and print journals such as Software Magazine, where he writes a column on Writing Secure Code.

About Foundstone Professional Services

Foundstone Professional Services, a division of McAfee, offers a unique combination of services and education to help organizations continuously and measurably protect the most important assets from the most critical threats. Through a strategic approach to security, Foundstone identifies, recommends, and implements the right balance of technology, people, and process to manage digital risk and leverage security investments more effectively.

Foundstone's Secure Software Security Initiative (S3i™) services help organizations design and engineer secure software. By building in security throughout the Software Development Lifecycle, organizations can significantly reduce their risk of malicious attacks and minimize costly remediation efforts. Services include:

  • Source code audits
  • Software design and architecture reviews
  • Threat modeling
  • Web application penetration testing
  • Software security metrics and measurement

For more information about Foundstone S3i services, go to www.foundstone.com/s3i.

Foundstone S3i training is designed to teach programmers and application developers how to build secure software and to write secure code. Classes include:

For the latest course schedule, go to www.foundstone.com/education.

© Microsoft Corporation. All rights reserved.