Chapter 5 – Architecture and Design Review for Security

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Microsoft Corporation

Published: June 2003

Last Revised: January 2006

Applies to:

• Web Applications
• ASP.NET version 1.1
• .NET Framework version 1.1

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.

Summary: This chapter provides a comprehensive set of questions to ask when you perform a security review of your application architecture and design. The chapter includes deployment and infrastructure considerations, application architecture and design review points and a tier by tier analysis that covers the Web server, application server and database server.

Contents

In This Chapter
Overview
How to Use This Chapter
Architecture and Design Review Process
Deployment and Infrastructure Considerations
Input Validation
Authentication
Authorization
Configuration Management
Sensitive Data
Session Management
Cryptography
Parameter Manipulation
Exception Management
Auditing and Logging
Summary
Additional Resources

In This Chapter

• Analyzing and reviewing application architecture and design
• Identifying key application deployment and infrastructure security considerations

Overview

To build a secure Web application, you need an appropriate architecture and design. The cost and effort of retrofitting security after development are too high. An architecture and design review helps you validate the security-related design features of your application before you start the development phase. This allows you to identify and fix potential vulnerabilities before they can be exploited and before the fix requires a substantial reengineering effort.

If you have already created your application, you should still review this chapter and then revisit the concepts, principles, and techniques that you used during your application design.

How to Use This Chapter

This chapter gives you the questions to ask when performing a thorough review of your architecture design. The following are recommendations on how to use this chapter:

• Integrate a security review into your architecture design process. Start early on, and as your design changes, review those changes with the steps given in this chapter.
• Evolve your security review. This chapter provides questions that you can ask to improve the security of your design. To complete the review process, you might also need to add specific questions that are unique to your application.
• Know the threats you are reviewing against. Chapter 2, "Threats and Countermeasures," lists the threats that affect the various components and layers that make up your application. Knowing these threats is essential to improving the results of your review process.

Architecture and Design Review Process

The architecture and design review process analyzes the architecture and design from a security perspective. If you have just completed the design, the design documentation can help you with this process. Regardless of how comprehensive your design documentation is, you must be able to decompose your application and be able to identify key items, including trust boundaries, data flow, entry points, and privileged code. You must also know the physical deployment configuration of your application. Pay attention to the design approaches you have adopted for those areas that most commonly exhibit vulnerabilities. This guide refers to these as application vulnerability categories.

Consider the following aspects when you review the architecture and design of your application:

• Deployment and infrastructure. You review the design of your application in relation to the target deployment environment and the associated security policies. You also consider the restrictions imposed by the underlying infrastructure-layer security.
• Application architecture and design. You review the approach to critical areas in your application, including authentication, authorization, input validation, exception management, and other areas. You can use the application vulnerability categories as a roadmap and to ensure that you do not miss any key areas during the review.
• Tier-by-tier analysis. You walk through the logical tiers of your application and examine the security of ASP.NET Web pages and controls, Web services, serviced components, Microsoft .NET Remoting, data access code, and others.

Figure 5.1 shows this three-pronged approach to the review process.

Figure 5.1

Application review

The remainder of this chapter presents the key considerations and questions to ask during the review process for each of these distinct areas.

Deployment and Infrastructure Considerations

Examine the security settings that the underlying network and host infrastructure offer to the application, and examine any restrictions that the target environment might impose. Also consider your deployment topology and the impact of middle-tier application servers, perimeter zones, and internal firewalls on your design.

Review the following questions to identify potential deployment and infrastructure issues:

• Does the network provide secure communication?
• Does your deployment topology include an internal firewall?
• Does your deployment topology include a remote application server?
• What restrictions does infrastructure security impose?
• Have you considered Web farm issues?
• What trust levels does the target environment support?

Does the Network Provide Secure Communication?

Your data is at its most vulnerable while in transit between a client and server, or server to server. How private should the data be? Are you legally responsible for customer data?

While your application is responsible for handling and transforming data securely prior to transit, the network is responsible for the integrity and privacy of the data as it transmits. Use an appropriate encryption algorithm when the data must remain private. Additionally, make sure that your network devices are secured because they maintain network integrity.

Does Your Deployment Topology Include an Internal Firewall?

If an internal firewall separates your Web server from an application server or a database server, review the following questions to ensure that your design accommodates this:

• How do downstream servers authenticate the Web server?

  If you use domain accounts and Windows authentication, does the firewall open the necessary ports? If not, or if the Web server and downstream server are in separate domains, you can use mirrored local accounts. For example, you can duplicate the least-privileged ASP.NET process identity account that is used to run the Web application on the database server.

• Do you use distributed transactions?

  If the Web server initiates distributed transactions using the services of the Microsoft Distributed Transaction Coordinator (DTC), does the internal firewall open the necessary ports for DTC communication?

  For more information about using the DTC through a firewall, see Microsoft Knowledge Base article 250367, "INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall."

Does Your Deployment Topology Include a Remote Application Server?

If your deployment topology includes a physically remote middle tier, review the following questions:

• Do you use Enterprise Services?

  If so, have you restricted the DCOM port range and does any internal firewall open these ports?

  Note   In some scenarios, using a middle-tier Web service as a front end to the Enterprise Services application is a superior design choice. With this approach, the Web server can communicate with the application server through port 80 using Simple Object Access Protocol (SOAP).

  For more information, see the following Microsoft Knowledge Base articles:

  • Article 312960, "Cannot Set Fixed Endpoint for a COM+ Application"
  • Article 259011, "SAMPLE: A Simple DCOM Client Server Test Application"
  • Article 248809, "PRB: DCOM Does Not Work over NAT-Based Firewall"
  • Article 154596, "HOWTO: Configure RPC Dynamic Port Allocation to Work w/Firewall"

• Do you use .NET Remoting?

  Remoting is designed to be used in trusted server scenarios. Does the network support an IPSec policy that ensures that your middle-tier Remoting components can only be accessed from the Web server? Does ASP.NET host your remote components to support authentication and authorization?

• Do you use Web services?

  If so, how do middle-tier Web services authenticate the Web application? Does the Web application configure credentials on the Web service proxy so that the Web service can authenticate the Web server? If not, how does the Web service identify the caller?

What Restrictions Does Infrastructure Security Impose?

Does your design make any assumptions that the host infrastructure security restrictions will invalidate? For example, the security restrictions may require design tradeoffs based on the availability of required services, protocols, or account privileges. Review the following questions:

• Do you rely on services or protocols that might not be available?

  Services and protocols that are available in the development and test environments might not be available in the production environment. Communicate with the team responsible for the infrastructure security to understand the restrictions and requirements.

• Do you rely on sensitive account privileges?

  Your design should use least privileged process, service, and user accounts. Do you perform operations that require sensitive privileges that might not be permitted?

  For example, does your application need to create thread-level impersonation tokens to create service identities for resource access? This requires the "Act as part of the operating system" privilege, which should not be granted to Web server processes because of the increased security risk associated with a process compromise. If this feature is required, your design should compartmentalize the higher privileges, for example, in an out-of-process Enterprise Services application.

  Note   If you are running ASP.NET 2.0 on Microsoft Windows Server™ 2003 and are using the Win32 LogonUser API for creating thread-level impersonation tokens, you do not need to grant the "Act as part of operating system" privilege to the Web server process identity.

  However, if you are using protocol transition to access local resources, you still need to grant the "Act as part of operating system" privilege to the Web server process identify. For more information, see How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0.

Have You Considered Web Farm Issues?

If your application is going to be deployed in a Web farm, you can make no assumptions about which server in the farm will process client requests. Successive requests from the same client may be served by separate servers. As a result, you need to consider the following issues:

• How are you managing session state?

  In a Web farm, you cannot manage session state on the Web server. Instead, your design must incorporate a remote state store on a server that is accessed by all the Web servers in the farm. For more information, see "Session Management" later in this chapter.

• Are you using machine-specific encryption keys?

  If you plan to use encryption to encrypt data in a shared data source, such as a database, the encryption and decryption keys must be the same across all machines in the farm. Check that your design does not require encryption mechanisms that require machine affinity.

• Are you using Forms authentication or protected view state?

  If so, you are reliant upon the <machineKey> settings. In a Web farm, you must use common key across all servers.

• Are you using Secure Sockets Layer (SSL)?

  If you use SSL to encrypt the traffic between browser and Web server, where do you terminate the SSL connection? Your options include the Web server, a Web server with an accelerator card, or a load balancer with an accelerator card. Terminating the SSL session at a load balancer with an accelerator card generally offers the best performance, particularly for sites with large numbers of connections.

  If you terminate SSL at the load balancer, network traffic is not encrypted from the load balancer to the Web server. This means that an attacker can potentially sniff network traffic after the data is decrypted, while it is in transit between the load balancer and Web server. You can address this threat either by ensuring that the Web server environment is physically secured or by using transport-level encryption provided by IPSec policies to protect internal data center links.

What Trust Levels Does the Target Environment Support?

The code access security trust level of the target environment determines the resources your code can access and the privileged operations it can perform. Check the supported trust level of your target environment. If your Web application is allowed to run with Full trust, your code can access any resources, subject to operating system security.

If your Web application must run at a reduced trust level, this limits the types of resources and privileged operations your code can perform. In partial trust scenarios, your design should sandbox your privileged code. You should also use separate assemblies to isolate your privileged code. This is done so that the privileged code can be configured separately from the rest of the application and granted the necessary additional code access permissions.

For more information, see Chapter 9, "Using Code Access Security with ASP.NET."

Note   Trust levels are often an issue if you are planning to deploy your application onto a shared server, or if your application is going to be run by a hosting company. In these cases, check the security policy and find out what trust levels it mandates for Web applications.

Input Validation

Examine how your application validates input because many Web application attacks use deliberately malformed input . SQL injection, cross-site scripting (XSS), buffer overflow, code injection, and numerous other denial of service and elevation of privilege attacks can exploit poor input validation. Table 5.1 highlights the most common input validation vulnerabilities.

Table 5.1   Common Input Validation Vulnerabilities

Vulnerability	Implications
Non-validated input in the Hypertext Markup Language (HTML) output stream	The application is susceptible to XSS attacks.
Non-validated input used to generate SQL queries	The application is susceptible to SQL injection attacks.
Reliance on client-side validation	Client validation is easily bypassed.
Use of input file names, URLs, or user names for security decisions	The application is susceptible to canonicalization bugs, leading to security flaws.
Application-only filters for malicious input	This is almost impossible to do correctly because of the enormous range of potentially malicious input. The application should constrain, reject, and sanitize input.

Review the following questions to help you identify potential input validation security issues:

• How do you validate input?
• What do you do with the input?

How Do You Validate Input?

What approach to input validation does your design specify? First, your design should lay out the strategy. Your application should constrain, reject, and sanitize all of the input it receives. Constraining input is the best approach because validating data for known valid types, patterns, and ranges is much easier than validating data by looking for known bad characters. With a defense in depth strategy, you should also reject known bad input and sanitize input.

The following questions can help you identify potential vulnerabilities:

• Do you know your entry points?

  Make sure the design identifies entry points of the application so that you can track what happens to individual input fields. Consider Web page input, input to components and Web services, and input from databases.

• Do you know your trust boundaries?

  Input validation is not always necessary if the input is passed from a trusted source inside your trust boundary, but it should be considered mandatory if the input is passed from sources that are not trusted.

• Do you validate Web page input?

  Do not consider the end user as a trusted source of data. Make sure you validate regular and hidden form fields, query strings, and cookies.

• Do you validate arguments that are passed to your components or Web services?

  The only case where it might be safe not to do so is where data is received from inside the current trust boundary. However, with a defense in depth strategy, multiple validation layers are recommended.

• Do you validate data that is retrieved from a database?

  You should also validate this form of input, especially if other applications write to the database. Make no assumptions about how thorough the input validation of the other application is.

• Do you centralize your approach?

  For common types of input fields, examine whether or not you are using common validation and filtering libraries to ensure that validation rules are performed consistently.

• Do you rely on client-side validation?

  Do not. Client-side validation can be used to reduce the number of round trips to the server, but do not rely on it for security because it is easy to bypass. Validate all input at the server.

What Do You Do with the Input?

Check what your application does with its input because different types of processing can lead to various types of vulnerabilities. For example, if you use input in SQL queries your application is potentially vulnerable to SQL injection.

Review the following questions to help you identify possible vulnerabilities:

• Is your application susceptible to canonicalization issues?

  Check whether your application uses names based on input to make security decisions. For example, does it accept user names, file names, or URLs? These are notorious for canonicalization bugs because of the many ways that the names can be represented. If your application does accept names as input, check that they are validated and converted to their canonical representation before processing.

• Is your application susceptible to SQL injection attacks?

  Pay close attention to any input field that you use to form a SQL database query. Check that these fields are suitably validated for type, format, length, and range. Also check how the queries are generated. If you use parameterized stored procedures, input parameters are treated as literals and are not treated as executable code. This is effective risk mitigation.

• Is your application susceptible to XSS attacks?

  If you include input fields in the HTML output stream, you might be vulnerable to XSS. Check that input is validated and that output is encoded. Pay close attention to how input fields that accept a range of HTML characters are processed.

Authentication

Examine how your application authenticates its callers, where it uses authentication, and how it ensures that credentials remain secure while in storage and when passed over the network. Vulnerabilities in authentication can make your application susceptible to spoofing attacks, dictionary attacks, session hijacking, and other attacks. Table 5.2 highlights the most common authentication vulnerabilities.

Table 5.2   Common Authentication Vulnerabilities

Vulnerability	Implications
Weak passwords	The risk of password cracking and dictionary attacks increase.
Clear text credentials in configuration files	Insiders who can access the server or attackers who exploit a host vulnerability to download the configuration file have immediate access to credentials.
Passing clear text credentials over the network	Attackers can monitor the network to steal authentication credentials and spoof identity.
Over-privileged accounts	The risks associated with a process or account compromise increase.
Long sessions	The risks associated with session hijacking increase.
Mixing personalization with authentication	Personalization data is suited to persistent cookies. Authentication cookies should not be persisted.

Review the following questions to identify potential vulnerabilities in the way your application performs authentication:

• Do you separate public and restricted access?
• Have you identified service account requirements?
• How do you authenticate the caller?
• How do you authenticate with the database?
• Do you enforce strong account management practices?

Do You Separate Public and Restricted Access?

If your application provides public areas that do not require authentication and restricted areas that do require authentication, examine how your site design distinguishes between the two. You should use separate subfolders for restricted pages and resources and then secure those folders in Internet Information Services (IIS) by configuring them to require SSL. This approach allows you to provide security for sensitive data and authentication cookies using SSL in only those areas of your site that need it. You avoid the added performance hit associated with SSL across the whole site.

Have You Identified Service Account Requirements?

Your design should identify the range of service accounts that is required to connect to different resources, including databases, directory services, and other types of remote network resources. Make sure that the design does not require a single, highly privileged account with sufficient privileges to connect to the range of different resource types.

• Does the design require least privileged accounts?

  Have you identified which resources and operations require which privileges? Check that the design identifies precisely which privileges each account requires to perform its specific function and use least privileged accounts in all cases.

• Does the application need to maintain service account credentials?

  If so make sure that the credentials are encrypted and held in a restricted location, such as a registry key with a restricted access control list (ACL).

How Do You Authenticate the Caller?

Review the following aspects of authenticating a caller. The aspects you use depend on the type of authentication your design uses.

• Do you pass clear text credentials over the wire?

  If you use Forms or Basic authentication, or if you use Web services and pass credentials in SOAP headers, make sure that you use SSL to protect the credentials in transit.

• Do you implement your own user store?

  If so, check where and how the user credentials will be stored. A common mistake is to store plaintext or encrypted passwords in the user store. Instead, you should store a hash value of the password and a random salt for verification.

  If you validate credentials against a SQL Server user store, pay close attention to the input user names and passwords. Check for the malicious injection of SQL characters.

• Do you use Forms authentication?

  If so, in addition to using SSL to protect the credentials, you should use SSL to protect the authentication cookie. Also check that your design uses a limited session lifetime to counter the threat of cookie replay attacks and check that the cookie is encrypted and tamper-proof.

For more information about Forms authentication, see Chapter 10, "Building Secure ASP.NET Pages and Controls" and Chapter 19, "Securing Your ASP.NET Application and Web Services."

How Do You Authenticate with the Database?

When your application connects to the database, examine what authentication mechanism you will use, what account or accounts you plan to use, and how you plan to authorize the application in the database.

The following questions help review your approach to database authentication:

• Do you use SQL authentication?

  Ideally, your design should use Windows authentication to connect to SQL Server because this is an inherently more secure approach. If you use SQL authentication, examine how you plan to secure credentials over the network and in database connection strings.

  If your network infrastructure does not provide IPSec encrypted channels, make sure a server certificate is installed on the database to provide automatic SQL credential encryption. Also examine how you plan to secure database connection strings because these strings contain SQL account user names and passwords.

• Do you use the process account?

  If you use the process account of the application and connect to SQL Server using Windows authentication, make sure that your design assumes a least privileged account. The local ASPNET account is provided for this purpose, although with local accounts, you need to create a duplicate account on the database server.

  Note   If you are running ASP.NET with IIS 6.0 on Windows Server 2003 in process isolation mode, the default process identity account is identified in the network as DomainName\MachineName$, You can use this identity to provide access to the database while using Windows authentication.

  If you plan to use a domain account, make sure that it is a least privileged account and check that all intervening firewalls support Windows authentication by opening the relevant ports.

• Do you use service accounts?

  If your design requires multiple identities to support more granular authorization in the database, examine how you plan to store the account credentials (ideally they are encrypted using the Data Protection API (DPAPI) and held in a secured registry key) and how you are going to use the service identity.

  Note   If you are running ASP.NET 2.0 on Microsoft Windows Server™ 2003 and are using the Win32 LogonUser API for creating thread-level impersonation tokens, you do not need to grant the "Act as part of operating system" privilege to the Web server process identity.

  However, if you are using protocol transition to access local resources, you still need to grant the "Act as part of operating system" privilege to the Web server process identify. For more information, see How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0.

  Also examine which process will be used to create the impersonated security context using the service account. This should not be done by the ASP.NET application process on Microsoft Windows 2000 because it forces you to increase the privileges of the process account and grant the "Act as part of the operation system" privilege. This should be avoided because it significantly increases the risk factor.

• Have you considered using the anonymous Internet user identity?

  For applications that use Forms or Passport authentication, you can configure a separate anonymous user account for each application. Next, you can enable impersonation and then use the anonymous identity to access the database. This approach accommodates separate authorization and identity tracking for separate applications on the same Web server.

• Do you use the original user identity?

  If your design requires impersonation of the original caller, you need to consider whether or not the approach provides sufficient scalability because connection pooling is ineffective. An alternative approach is to flow the identity of the original caller at the application level through trusted query parameters.

• How do you store database connection strings?

  If database connection strings are hard coded or stored in clear text in configuration files or the COM+ catalog, it makes them vulnerable. Instead, you should encrypt them and restrict access to the encrypted data.

For more information about the different options for connecting to SQL Server and about storing database connection strings securely, see Chapter 14, "Building Secure Data Access."

Do You Enforce Strong Account Management Practices?

The use of strong passwords, restricted login attempts, and other best practice account management policies can be enforced by Windows security policy if your application uses Windows authentication. Otherwise, the application layer is responsible for this. Review the following aspects of the account management of your application:

• Does your application enforce strong passwords?

  For example, do your ASP.NET Web pages use regular expressions to verify password complexity rules?

  Note   If you are using the Membership feature of ASP.NET 2.0, you can configure the providers to enforce strong passwords. For more information, see "How To: Protect Forms Authentication in ASP.NET 2.0".

• Do you restrict the number of failed login attempts?

  Doing so can help counter the threat of dictionary attacks.

• Do you reveal too much information in the event of failure?

  Make sure you do not display messages such as "Incorrect password" because this tells malicious users that the user name is correct. This allows them to focus their efforts on cracking passwords.

• Do you enforce a periodic change of passwords?

  This is recommended because otherwise there is a high probability that a user will not change his or her password, which makes it more vulnerable.

• Can you quickly disable accounts in the event of compromise?

  If an account is compromised, can you easily disable the account to prevent the attacker from continuing to use the account?

• Does your application record login attempts?

  Recording failed login attempts is an effective way to detect an attacker who is attempting to break in.

Authorization

Examine how your application authorizes its users. Also examine how your application is authorized inside the database and how access to system-level resources is controlled. Authorization vulnerabilities can result in information disclosure, data tampering, and elevation of privileges. A defense in depth strategy is the key security principle that you can apply to the authorization strategy of your application. Table 5.3 highlights the most common authorization vulnerabilities.

Table 5.3   Common Authorization Vulnerabilities

Vulnerability	Implications
Reliance on a single gatekeeper	If the gatekeeper is bypassed or is improperly configured, a user gains unauthorized access.
Failing to lock down system resources against application identities	An attacker can coerce the application into accessing restricted system resources.
Failing to limit database access to specified stored procedures	An attacker mounts a SQL injection attack to retrieve, manipulate, or destroy data.
Inadequate separation of privileges	There is no accountability or ability to perform per user authorization.

Review the following questions to help validate the authorization strategy of your application design:

• How do you authorize end users?
• How do you authorize the application in the database?
• How do you restrict access to system-level resources?

How Do You Authorize End Users?

You should consider authorization from two perspectives at design time. First, consider end-user authorization. Which users can access which resources and perform which operations? Secondly, how do you prevent malicious users from using the application to access system level resources? Review the following questions to validate the authorization strategy of your application:

• Do you use a defense in depth strategy?

  Make sure that your design does not rely on a single gatekeeper to enforce access control. Consider what happens if this gatekeeper fails or if an attack manages to bypass it.

• Which gatekeepers are used?

  Options include IIS Web permissions, NTFS permissions, ASP.NET file authorization (which applies only with Windows authentication), URL authorization, and principal permission demands. If certain types are not used, make sure you know the reasons why not.

• Do you use a role-based approach?

  If so, how are the role lists maintained and how secure are the administration interfaces that are required to do this?

• Do your roles provide adequate privilege separation?

  Does your design provide the right degree of granularity so that the privileges that are associated with distinct user roles are adequately separated? Avoid situations where roles are granted elevated privileges just to satisfy the requirements of certain users. Consider adding new roles instead.

How Do You Authorize the Application in the Database?

The accounts that your application uses to connect to the database should have restricted capabilities that are sufficient for the application requirements, but no more.

• Does the application access the database using stored procedures?

  This is recommended because the login of the application can only be granted permissions to access the specified stored procedures. The login can be restricted from performing direct create/read/update/delete (CRUD) operations against the database.

  This benefits security, and performance and future maintainability also benefit.

For more information about database authorization approaches, see Chapter 14, "Building Secure Data Access."

How Do You Restrict Access to System-Level Resources?

When you design your application, consider the restrictions that will be placed on the application in terms of which system-level resources it can access. The application should only be granted access to the minimum required resources. This is a risk mitigation strategy that limits damage if an application is compromised. Consider the following issues:

• Does your design use code access security?

  Code access security provides a resource constraint model that can prevent code (and Web applications) from accessing specific types of system-level resources. When you use code access security, it inevitably influences your design. Identify whether or not you want to include code access security in your design plans, and then design accordingly by isolating and sandboxing privileged code and placing resource access code in its own separate assemblies.

• What identities does your application use?

  Your design should identify all of the identities that the application uses, including the process identity, and any impersonated identities, including anonymous Internet user accounts and service identities. The design should also indicate to which resources these identities require access.

  At deployment time, the appropriate ACLs can be configured on system-level resources to ensure that the identities of the application only have access to the resources they require.

For more information about designing for code access security, see Chapter 9, "Using Code Access Security with ASP.NET."

Configuration Management

If your application provides an administration interface that allows it to be configured, examine how the administration interfaces are secured. Also examine how sensitive configuration data is secured. Table 5.4 shows the most common configuration management vulnerabilities.

Table 5.4   Common ConfigurationManagement Vulnerabilities

Vulnerability	Implications
Insecure administration interfaces	Unauthorized users can reconfigure your application and access sensitive data.
Insecure configuration stores	Unauthorized users can access configuration stores and obtain secrets, such as account names and passwords, and database connection details.
Clear text configuration data	Anyone that can log in to the server can view sensitive configuration data.
Too many administrators	This makes it difficult to audit and vet administrators.
Over-privileged process accounts and service accounts	This can allow privilege escalation attacks.

Use the following questions to help validate the approach of your application design to configuration management:

• Do you support remote administration?
• Do you secure configuration stores?
• Do you separate administrator privileges?

Do You Support Remote Administration?

If your design specifies remote administration, then you must secure the administration interfaces and configuration stores because of the sensitive nature of the operations and the data that is accessible over the administration interface. Review the following aspects of your remote administration design:

• Do you use strong authentication?

  All administration interface users should be required to authenticate. Use strong authentication, such as Windows or client-certificate authentication.

• Do you encrypt the network traffic?

  Use encrypted communication channels, such as those provided by IPSec or virtual private network (VPN) connections. Do not support remote administration over insecure channels. IPSec allows you to limit the identity and number of client machines that can be used to administer the server.

Do You Secure Configuration Stores?

Identify the configuration stores of your application and then examine your approach to restricting access to the stores and securing the data inside the stores.

• Is your configuration store in the Web space?

  Configuration data that is held in files in the Web space is considered less secure than data that is held outside the Web space. Host configuration mistakes or undiscovered bugs could potentially allow an attacker to retrieve and download configuration files over HTTP.

• Is the data in the configuration store secure?

  Make sure that key items of configuration data, such as database connection strings, encryption keys, and service account credentials, are encrypted inside the store.

• How is access to the configuration store restricted?

  Check that the administration interface provides the necessary authorization to ensure that only authenticated administrators can access and manipulate the data.

Do You Separate Administrator Privileges?

If your administration interfaces support different functionalities — for example, site content updates, service account reconfiguration, and database connection details — verify that your administration interfaces support role-based authorization to differentiate between content developers and operators or system administrators. For example, the person who updates static Web site content should not necessarily be allowed to alter the credit limit of a customer or reconfigure a database connection string.

Sensitive Data

Examine how your application handles sensitive data in store, in application memory, and while in transit across the network. Table 5.5 shows the most common vulnerabilities that are associated with handling sensitive data.

Table 5.5   Common Vulnerabilities with Handling Sensitive Data

Vulnerability	Implications
Storing secrets when you do not need to	This drastically increases the security risk as opposed to not storing the secret in the first place.
Storing secrets in code	If the code is on the server, an attacker might be able to download it. Secrets are visible in binary assemblies.
Storing secrets in clear text	Anyone who can log on to the server can see secret data.
Passing sensitive data in clear text over networks	Eavesdroppers can monitor the network to reveal and tamper with the data.

Use the following questions to help validate the handling of sensitive data by your application:

• Do you store secrets?
• How do you store sensitive data?
• Do you pass sensitive data over the network?
• Do you log sensitive data?

Do You Store Secrets?

Secrets include application configuration data, such as account passwords and encryption keys. If possible, identify alternate design approaches that remove any reason to store secrets. If you handle secrets, let the platform handle them so that the burden is lifted from your application wherever possible. If you do store secrets, review the following questions:

• Can you avoid storing the secret?

  If you use an alternative implementation technique, it could remove the need to store secrets. For example, if all you need to do is verify that a user knows a password, you do not need to store passwords. Instead, store a one-way hash value of password and salt.

  Also, if you use Windows authentication, you avoid storing connection strings with embedded credentials.

• How do you store secrets?

  If you use encryption, how do you secure the encryption keys? Consider using platform-provided DPAPI encryption that takes care of the key management for you.

• Where do you store secrets?

  Examine how your application stores its encrypted data. For maximum security, access to the encrypted data should be restricted with Windows ACLs. Check that the application does not store secrets in clear text or in source code.

  If you use the Local Security Authority (LSA), the code that retrieves the secret has to run with administrator privileges, which increases risk. An alternative approach that does not require extended privileges is to use DPAPI.

• How do you process secrets?

  Examine how your application accesses the secrets and how long they are retained in memory in clear text form. Secrets should generally be retrieved on demand, used for the smallest amount of time possible, and then discarded.

• Do you store secrets in cookies?

  If so, make sure the cookie is encrypted and is not persisted on the client computer.

How Do You Store Sensitive Data?

If you store sensitive application data, such as custom credit card details, examine how you protect the data.

• What encryption algorithm do you use? You should encrypt the data using a strong encryption algorithm with a large key size, such as Triple DES.
• How do you secure the encryption keys? The data is only as secure as the encryption key, so examine how you secure the key. Ideally, encrypt the key with DPAPI and secure it in a restricted location, for example, a registry key.

Do You Pass Sensitive Data Over the Network?

If you pass sensitive data over the network, check that the data is either encrypted by the application or that the data is only passed over encrypted communication links.

Do You Log Sensitive Data?

Examine whether or not your application (or the host) logs sensitive data such as user account passwords in clear text log files. You should generally avoid this. Make sure the application does not pass sensitive data in query strings because these are logged and are also clearly visible in the client's browser address bar.

Session Management

Because Web applications are built on the stateless HTTP protocol, session management is an application-level responsibility. Examine the approach to session management by your application because it directly affects the overall security of your application. Table 5.6 shows the most common vulnerabilities associated with session management.

Table 5.6   Common Session Management Vulnerabilities

Vulnerability	Implications
Passing session identifiers over unencrypted channels	Attackers can capture session identifiers to spoof identity.
Prolonged session lifetime	This increases the risk of session hijacking and replay attacks.
Insecure session state stores	Attackers can access the private session data of a user.
Session identifiers in query strings	Session identifiers can easily be modified at the client to spoof identity and access the application as another user.

Use the following questions to help validate the handling of sensitive data by your application:

• How are session identifiers exchanged?
• Do you restrict session lifetime?
• How is the session state store secured?

How Are Session Identifiers Exchanged?

Examine the session identifier that your application uses to manage user sessions and how these session identifiers are exchanged. Consider the following:

• Do you pass session identifiers over unencrypted channels?

  If you track session state with session identifiers — for example, tokens contained in cookies — examine whether or not the identifier or cookie is only passed over an encrypted channel, such as SSL.

• Do you encrypt session cookies?

  If you use Forms authentication, make sure your application encrypts the authentication cookies using the protection="All" attribute on the <forms> element. This practice is recommended in addition to SSL to mitigate the risk of an XSS attack that manages to steal the authentication cookie of a user.

• Do you pass session identifiers in query strings?

  Make sure that your application does not pass session identifiers in query strings. These strings can be easily modified at the client, which would allow a user to access the application as another user, access the private data of other users, and potentially elevate privileges.

Do You Restrict Session Lifetime?

Examine how long your application considers a session identifier valid. The application should limit this time to mitigate the threat of session hijacking and replay attacks.

How Is the Session State Store Secured?

Examine how your application stores session state. Session state can be stored in the Web application process, the ASP.NET session state service, or a SQL Server state store. If you use a remote state store, make sure that the link from the Web server to the remote store is encrypted with IPSec or SSL to protect data over the wire.

For more information about securing ASP.NET session state, see "Session State" in Chapter 19, "Securing Your ASP.NET Application and Web Services."

Cryptography

If your application uses cryptography to provide security, examine what it is used for and the way it is used. Table 5.7 shows the most common vulnerabilities relating to cryptography.

Table 5.7   Common Cryptography Vulnerabilities

Vulnerability	Implications
Using custom cryptography	This is almost certainly less secure than the tried and tested platform-provided cryptography.
Using the wrong algorithm or too small a key size	Newer algorithms increase security. Larger key sizes increase security.
Failing to secure encryption keys	Encrypted data is only as secure as the encryption key.
Using the same key for a prolonged period of time	A static key is more likely to be discovered over time.

Review the following questions to help validate the handling of sensitive data by your application:

• Why do you use particular algorithms?
• How do you secure encryption keys?

Why Do You Use Particular Algorithms?

Cryptography only provides real security if it is used appropriately and the right algorithms are used for the right job. The strength of the algorithm is also important. Review the following questions to review your use of cryptographic algorithms:

• Do you develop your own cryptography?

  Do not. Cryptographic algorithms and routines are notoriously difficult to develop and get right. Custom implementations frequently result in weak protection and are almost always less secure than the proven platform-provided services.

• Do you use the right algorithm with an adequate key size?

  Examine what algorithms your application uses and for what purpose. Larger key sizes result in improved security, but performance suffers. Stronger encryption is most important for persisted data that is retained in data stores for prolonged periods of time.

For more information about choosing an appropriate algorithm and key size, see the Cryptography section in Chapter 4, "Design Guidelines for Secure Web Applications."

How Do You Secure Encryption Keys?

The encrypted data is only as secure as the key. To decipher encrypted data, an attacker must be able to retrieve the key and the cipher text. Therefore, examine your design to ensure that the encryption keys and the encrypted data are secured. Consider the following review questions:

• How do you secure the encryption key?

  If you use DPAPI, the platform manages the key for you. Otherwise, the application is responsible for key management. Examine how your application secures its encryption keys. A good approach is to use DPAPI to encrypt the encryption keys that are required by other forms of encryption. Then securely store the encrypted key, for example, by placing it in the registry beneath a key configured with a restricted ACL.

• How often are keys recycled?

  Do not overuse keys. The longer the same key is used, the more likely it is to be discovered. Does your design consider how and how often you are going to recycle keys and how they are going to be distributed and installed on your servers?

Parameter Manipulation

Examine how your application uses parameters. These parameters include form fields, query strings, cookies, HTTP headers, and view state that are passed between client and server. If you pass sensitive data, such as session identifiers, using parameters such as query strings, a malicious client can easily bypass your server side checks with simple parameter manipulation. Table 5.8 shows the most common parameter manipulation vulnerabilities.

Table 5.8   Common Parameter Manipulation Vulnerabilities

Vulnerability	Implications
Failing to validate all input parameters	Your application is susceptible to denial of service attacks and code injection attacks, including SQL injection and XSS.
Sensitive data in unencrypted cookies	Cookie data can be changed at the client or it can be captured and changed as it is passed over the network.
Sensitive data in query strings and form fields	This is easily changed on the client.
Trusting HTTP header information	This is easily changed on the client.
Unprotected view state	This is easily changed on the client.

Examine the following questions to help ensure that your design is not susceptible to parameter manipulation attacks:

• Do you validate all input parameters?
• Do you pass sensitive data in parameters?
• Do you use HTTP header data for security?

Do You Validate All Input Parameters?

Check that your application validates all input parameters, including regular and hidden form fields, query strings, and cookies.

Do You Pass Sensitive Data in Parameters?

If your application passes sensitive data in parameters such as query strings or form fields, examine why your application favors this approach over the much more secure approach of passing a session identifier (for example, in an encrypted cookie). Use this information to associate the session with the state of a user that is maintained in the state store on the server. Consider the following review points:

• Do you encrypt cookies with sensitive data?

  If your application uses a cookie that contains sensitive data, such as a user name or a role list, make sure it is encrypted.

• Do you pass sensitive data in query strings or Form fields?

  This is not recommended because there is no easy way to prevent the manipulation of data in query strings or form fields. Instead, consider using encrypted session identifiers and store the sensitive data in the session state store on the server.

• Do you protect view state?

  If your Web pages or controls use view state to maintain state across HTTP requests, check that the view state is encrypted and checked for integrity with message authentication codes (MACs). You can configure this at the machine level or on a page-by-page basis.

Do You Use HTTP Header Data for Security?

Make sure that your Web application does not make security decisions based on information in HTTP headers because an attacker can easily manipulate the header. Do not rely on the value of the HTTP referer field to check that the request originated from a page that is generated by your Web application — this creates vulnerabilities. Doing this is inherently insecure because the referer field can easily be changed by the client.

Exception Management

Examine the way that your application handles error conditions. It is recommended that you consistently use structured exception handling. Also, check that your application does not reveal too much information when an exception occurs. Table 5.9 shows the two major exception management vulnerabilities.

Table 5.9   Common ExceptionManagement Vulnerabilities

Vulnerability	Implications
Failing to use structured exception handling	Your application is more susceptible to denial of service attacks and logic flaws, which can expose security vulnerabilities.
Revealing too much information to the client	An attacker can use this information to help plan and tune subsequent attacks.

Review the following questions to help ensure that your design is not susceptible to exception management security vulnerabilities:

• Do you use structured exception handling?
• Do you reveal too much information to the client?

Do You Use Structured Exception Handling?

Examine how your application uses structured exception handling. Your design should mandate that structured exception handling be used consistently throughout the entire application. This creates more robust applications and your application is less likely to be left in inconsistent states that can reveal security vulnerabilities.

Do You Reveal Too Much Information to the Client?

Make sure that a malicious user cannot exploit the overly detailed information that an error message contains. Review the following points:

• Do you catch, handle, and log exceptions on the server?

  Make sure that the application does not let internal exception conditions propagate beyond the application boundary. Exceptions should be caught and logged on the server and, if necessary, generic error messages should be returned to the client.

• Do you use a centralized exception management system?

  The best way to handle and log exceptions consistently throughout your application is to use a formalized exception management system. You can also tie this system into monitoring systems that can be used by the operations team for health and performance monitoring.

• Have you defined a set of custom error messages?

  Your design should define the custom error messages will be used by your application when critical errors occur. Make sure they do not contain any sensitive items of data that could be exploited by a malicious user.

For more information about designing and implementing an exception management framework for .NET applications, see MSDN article, "Exception Management in .NET," at https://msdn.microsoft.com/en-us/library/ms954599.aspx.

Auditing and Logging

Examine how your application uses auditing and logging. Besides preventing repudiation issues, regular log file analysis helps identify signs of intrusion. Table 5.10 shows the most common auditing and logging vulnerabilities.

Table 5.10   Common Auditing and Logging Vulnerabilities

Vulnerability	Implications
Failing to audit failed logons	Attempted break-ins go undetected.
Failing to secure audit files	An attacker can cover his or her tracks.
Failing to audit across application tiers	The threat of repudiation increases.

Review the following questions to help verify the approach to auditing and logging by your application:

• Have you identified key activities to audit?
• Have you considered how to flow original caller identity?
• Have you considered secure log file management policies?

Have You Identified Key Activities to Audit?

Your design should define which activities should be audited. Consider the following:

• Do you audit failed login attempts?

  This allows you to detect break-in and password-cracking attempts.

• Do you audit other key operations?

  Check that you audit other key events, including data retrieval, network communications, and administrative functions (such as enabling and disabling of logging).

Have You Considered How to Flow Original Caller Identity?

Your design should ensure that activity is audited across multiple application tiers. To do so, the identity of the original caller must be available at each tier.

• Do you audit across application tiers?

  Examine whether each tier audits activity as it should.

• How do you synchronize multiple logs?

  Log files may be needed in legal proceedings to prove crimes committed by individuals or to settle cases of repudiation. Generally, auditing is considered most authoritative if the audits are generated at the time of resource access and by the same routines that access the resource. Verify that the application design factors in log file synchronization and logs some form of request identifier to ensure that multiple log file entries can be correlated and related back to a single request.

• How do you flow the original caller identity?

  If you do not flow the original caller identity at the operating system level, for example, because of the limited scalability that this approach offers, identify how the application flows the original caller identity. This is required for cross-tier auditing (and potentially for authorization).

  Also, if multiple users are mapped to a single application role, check that the application logs the identity of the original caller.

Have You Considered Secure Log File Management Policies?

Check whether your application design factors in how log files are backed up, archived, and analyzed. Log files should be archived regularly to ensure that they do not fill up or start to cycle, and they should be regularly analyzed to detect signs of intrusion. Also ensure that any accounts used to perform the backup are least privileged and that you secure any additional communication channels exposed purely for the purpose of the backup.

Summary

By spending the time and effort up front to analyze and review your application architecture and design, you can improve its overall security by eliminating design-related vulnerabilities. It is much easier and less expensive to fix vulnerabilities at design time than it is later in the development cycle when substantial reengineering might be required.

By considering your design in relation to the target deployment environment and the security policies defined by that environment, you can help ensure a smooth and secure application deployment.

If your application has already been created, the architecture and design review is still an important part of the security assessment process that helps you fix vulnerabilities and improve future designs.

Additional Resources

For more information, see the following resources:

• For more information on designing, building and configuring authentication, authorization and secure communications across the tiers of a distributed Web application, see "Microsoft patterns & practices Volume I, Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication" at https://msdn.microsoft.com/en-us/library/aa302383.aspx.
• For a printable checklist, see Checklist: Architecture and Design Review" in the "Checklists" section of this guide.

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.