Improving Web Application Security: Threats and Countermeasures

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 local ASPNET 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.

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."