ASP.NET 2.0 Performance Guidelines - Security Considerations

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, John Allen, and Alex Mackman


Contents

Constrain Unwanted Web Server Traffic

Constrain the traffic to your Web Server to avoid unnecessary processing. For example, block invalid requests at your firewall to limit the load on your Web server. In addition, do the following:

  • Map unsupported extensions to the 404.dll file in IIS.
  • Use the UrlScan filter to control the verbs and the URL requests that you allow. Verbs that you might want to control include Get, Post, and SOAP.
  • Review your IIS logs. If the logs are full of traffic that you do not allow, investigate blocking that traffic at the firewall or filtering the traffic by using a reverse proxy.


References


Turn Off Authentication for Anonymous Access

Partition pages that require authenticated access from pages that support anonymous access. To avoid authentication overhead, set the authentication mode to None in the Web.config file in the directory that contains the anonymous pages. The following line shows how to set the authentication mode in the Web.config file.

<authentication mode="None" />

References


Validate User Input on the Client

Consider using client-side validation to avoid sending unwanted traffic to the server. However, do not trust client-side validation alone because it can easily be bypassed. For security reasons, you should implement the equivalent server-side checks for every client check.

References


Avoid Per-Request Impersonation

Per-request impersonation where you use the original caller's identity to access the database places severe scalability constraints on your application. Per-request impersonation prevents the effective use of database connection pooling. The trusted subsystem model is the preferred and scalable alternative. With this approach, you use a fixed service account to access the database and to pass the identity of the original caller at the application level if the identity of the original caller is required. For example, you might pass the identity of the original caller through stored procedure parameters.


References


Segregate Secure and Non-Secure Content

When you design the folder structure for your Web site, clearly differentiate between the publicly accessible areas and restricted areas that require authenticated access and Secure Sockets Layer (SSL). Use separate subfolders beneath the virtual root folder of your application to hold restricted pages such as forms logon pages, checkout pages, and any other pages that users transmit sensitive information to that needs to be secured by using HTTPS


Why

By segregating your application you can use HTTPS for specific pages without incurring the SSL performance overhead across your entire site. This improves performance on the pages that don't require SSL.


When

This guideline should be used whenever deploying a application that has mix of public and secure pages.


How

Use the following steps to secure pages in separate subfolders:


Structure your Web Site Structure you web site such that the secure pages that require authenticated access are placed in a subdirectory that is separate from the anonymously accessible pages. Here is the representation of the folder structure.

- http://serverName/appName (VDir)
|
|---Secure
|	|--- Login.aspx
|	|--- ShoppingCart.aspx
|
|---Non Secure
	|
	|----ProductInfo.aspx


Configure SSL for Secure folder In Microsoft Internet Information Services (IIS), configure the secure folder to require SSL. This sets the AccessSSL=true attribute for the folder in the IIS Metabase. Requests for pages in the secured folders are successful only if HTTPS is used for the request URL. Configure Access to Authenticated Users in Secure Folder Use an <authorization> element to ensure that only authenticated users can access secure pages. Place this element beneath the closing </system.web> tag, as shown here.

<location path="Secure" >
  <system.web>
     <authorization>
         <deny users="?" />
     </authorization>
  </system.web>
</location>        


Configure Access to All Users in Secure Folder Use the following configuration to ensure that unauthenticated users are allowed to access pages in the application's root directory. Place this configuration in the main <system.web> element.

<system.web>
  <authorization>
     <allow users="*" />
  </authorization>
</system.web>

Note If you use this type of site structure, your application must not rely on the user's identity on the non-SSL pages. In the preceding configuration, no forms authentication ticket is sent for requests for non-SSL pages. As a result, the user is considered anonymous. This has implications for related features, such as personalization, that require the user name.


Problem Example

An ASP.NET application for online shopping is deployed with all the pages in Virtual directory's root folder. As the site has some pages that needs to be secure, the site is configured to use SSL.

Unfortunately, since all the pages will be accessed using Https protocol, there will be SSL overhead even for the pages which do not require it.


Solution Example

An ASP.NET application is deployed with secure and non secure pages segregated as follows:

- http://serverName/appName (VDir)
|
|---Secure
|	|--- Login.aspx
|	|--- ShoppingCart.aspx
|
|
|----ProductInfo.aspx
|----Default.aspx

The Web.config file is configured so that only authenticated users can access the secured pages.

<location path="Secure" >
  <system.web>
     <authorization>
         <deny users="?" />
     </authorization>
  </system.web>
</location>

The main configuration element allows access to every one. This combination ensures that all uses can access the non-secured pages while only authenticated users can access the secured pages.

<system.web>
  <authorization>
     <allow users="*" />
  </authorization>
</system.web>


References


Only Use SSL for Pages That Require It

Using SSL is expensive. Only use SSL for pages that require it. This includes pages that contain or capture sensitive data, such as pages that accept credit card numbers and passwords. Use SSL only if the following conditions are true:

  • You want to encrypt the page data.
  • You want to guarantee that the server to which you send the data is the server that you expect.

For pages where you must use SSL, follow these guidelines:

  • Make the page size as small as possible.
  • Avoid using graphics that have large file sizes. If you use graphics, use graphics that have smaller file sizes and resolution. Or, use graphics from a site that is not secure. However, when you use graphics from a site that is not secure, Web browsers display a dialog box that asks the user if the user wants to display the content from the site that is not secure.


References


Use Absolute URLs for Navigation

Use absolute links instead of the relative links when redirecting between HTTPS and HTTP pages.


Why

Navigating between HTTPS and HTTP using redirects forces the protocol of the current page instead of the protocol of the target page. When your redirects use relative links (..\publicpage.aspx) to sites that are not secure from a site that uses HTTPS, these public pages are served using the HTTPS protocol. This use of the HTTPS protocol incurs unnecessary overhead and impacts application performance.


When

This guideline should be used when implementing redirects navigating between HTTPS and HTTP pages.


How

The following code fragment shows how to create a redirect from a page that uses HTTPS to a page that uses HTTP.

private void btnLogon_Click( object sender, System.EventArgs e )
{
 // Authenticate user
 // Once user is authenticated transfer to the default page, which is publicly accessible
 // Form an absolute path using the server name and v-dir name
 string serverName = 
        HttpUtility.UrlEncode(Request.ServerVariables["SERVER_NAME"]);
 string vdirName = Request.ApplicationPath;
 Response.Redirect("http://" + serverName + vdirName + 
                   "/Default.aspx");
}


Problem Example

An ASP.NET shopping application redirects authenticated users from the HTTPS login page to an HTTP Product Info page

Unfortunately the redirect is achieved with a relative link. This has the side effect of serving up the ProductInfo page through HTTPS instead of HTTP resulting in a negative performance impact.

protected void Button1_Click(object sender, EventArgs e)
{
  bool IsValidUser = false;
  
  // extract user id and password and validate the user and set the IsValidUser to true.
  if (IsValidUser)
  {
      Response.Redirect("..\ProductInfo.aspx");           
  }
  else
  {
      Response.Write("Invalid UserID and Password");
  }
}


Solution Example

An ASP.NET shopping application redirects authenticated users from the HTTPS login page to an HTTP Product Info page. The code redirects using an absolute path thus removing the overhead of using SSL for pages that don't require them.

protected void Button1_Click(object sender, EventArgs e)
{
  bool IsValidUser = false;
  
  // extract user id and password and validate the user and set the IsValidUser to true.
  if (IsValidUser)
  {
      Response.Redirect("http://ServerName/appName/ProductInfo.aspx");           
  }
  else
  {
      Response.Write("Invalid UserID and Password");
  }
} 


References


Consider Using SSL Hardware to Offload SSL Processing

Consider a hardware solution for SSL processing. Terminating SSL sessions at a load balancer by using a hardware accelerator generally offers better performance, particularly for sites that experience heavy use.


References


Tune SSL Timeout to Avoid SSL Session Expiration

If you are not using SSL hardware, tune the ServerCacheTimer property to avoid having to renegotiate the SSL handshakes with browser clients. The largest use of resources when you use SSL occurs during the initial handshake, where asymmetric public/private-key encryption is used. After a secure session key is generated and exchanged, faster, symmetric encryption is used to encrypt application data.

Monitor your SSL connections and increase the value of the ServerCacheTime registry entry if you find that a longer time is better for your scenario.


References

Personal tools